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Introduction 

This manual is intended to te a guide tc the philosophy and 
use of the programming lancuage Conniver, which is "complete, 11 
and running at the /J Let now. It assur.es food knowledge of 
Lisp, tut no knowledge of kicro-risnner, in whose icpleiLentation 
cany design decisions were cade that axe not to be expected to 
have consequences in Conniver, Those not familiar with Lisp 
should consult Weissman's (1967) Primer , the Lisp 1_.g 
Erorraraner 's Marual (McCarthy et. §l*i 1962), or Jon L* White's 
(1970) and others' (PDP-6, 1367) excellent demos here at our own 
I at. 

The first chapter of this manual, Basic Conr^ver, is intended 
to show the Lisp user what Conniver programs look like, and what 
data structure the systec provides for the user to interact with. 
By the time he is through with it, any Lisp writer should be able 
to write Conniver programs. Chapter the second, on hairy Control 
Structure , explains the frame structure underlying the Conniver 
programs and encourages you to use it* Here the miracle of 
generator functions is revealed; here, too, is demonstrated the 
rasi with which Conniver programs can do what jour old-fashioned 
Micro-Planner programs do. The third section of the Overview, en 
Ha? : y tata Structure , explains the context^layered data base in 

somewhat nore detail than in chapter one, and introduces seme 
new data types and data GtrLcture-canipulating iunctions. Ihe 
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section Cn lattern-Lirected Invocation explains the operation of 
tie Conniver matcher, used in the invoking of procedures 
associated with the data ba&c. The remaining sections are on 
implementation details, such as using the language, and using it 
in conjunction with Lisp. linally, the Appendix and Index 
provide a detailed fuide to the user who has grasped the Uisic 
principles of the language. 

Conniver eotcdies few original ideas, but is hopefuly an 
original combination of the good ideas of others. We must 
acknowledge Carl Hewitt's Planner language (liewitt, 1971) fcr 
giving us mest of our ideas about data structure, although 
Ccnniver looks at its world differently from Planner. The 
control structure, including the concepts "access" and "control, 11 

wns enon&ously influenced by Daniel C* Eobrow. (Bobrow and 
Wegfcreit, 1S72). The variable declaration syntax is closely 
related to the MUEDLE syntax developed by Christopher Reeve. The 
wry these ideas have been used is in large Leasure the way Joel 
Moses has thought they ought to be; if there is a "Conniver 
philosophy," a lot of it is his. 

Several people read the first draft of this overview and 
influenced this one, especially tavid licTonald, Terry Winograd, 
Sidney liarkovitz, and Jeff Kubin. The current semantics of data- 
property functions is fertly due to a suggestion by Michael 
Genesreth. last in this category, tut not least in one respect, 
is Michael Levin; his confusion at the terseness of some of my 
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explanations has core one step in avencinc the confusion of an 
entire feneration of programmers at his Lisp !•£* nanual. 

DVH 
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R sic Conniver 

Conniver is a piogranninc language aesifiied to u^Ute easy the 
definition of processes cooperating to solve prcblecia in the 
realm of Artificial Intelligence, it looks a let like Lisp, with 
two additions: 

(1) A systerc-naintained data tase 

(2) The ability to canipulate arbitrary control environments. 
The data base structure gives the user a generalized way of 

storing cost of the data in the world model he is creating* In 
addition, the data pool is hierarchical, so the user can run 
processes in independent, possibly conflicting contexts. 

An important type of datum in the data base is the itec , an 
arbitrary (but printable) list structure, such as 

(GCC1 (ITS! GCC1 IS FALSE)) 
or (JCKtf 1-ATES (SKY GIRLS}), 

but not <<((((<(((... or (MIL NIL iOL iOL NIL HIL... 

vith the restrictions that at any given point it be present or 
^ls nt from the data base. Iters are slipped in and out with the 
functions AED and REMOVE (which, like almost *n Conniver 
primitives, evaluate their ar£unients). For exarple, 

(AID '(JACK LIJ.ES LEAH)) 

(REMOVE '(JACK LIKTS TfiX)) 
-alee the item (JACK USES ULAN) present and the ite* (JACK LIKES 
.A:) absent. The ercuoents to ADD and REMOVE are skeletons 
whlchj upon substitution or the values ci* their variables, 
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specify iteris. Comiras indicate variable values, as in 

Ujjd *(,x gk ,i)3 

whe.e the commas specify that the item ("value of X" Oii "value of 
Y M ) is to be added to the current context, Tor example, if X = 
LAUKEilCE and Y = CHATTEKLY, then the skeleton specifies the iteiL 
(L/VRENCE OK CKAKHJiY)- 

The existence of contexts makes it easy to create ana 
rcmipulate hypothetical models. A context can ie regarded as a 
separate world model or data base of its own. AID and REiOVL 
always apply, implicitly or explicitly, to the cata base 
represented by a particular context. These models are not 
entirely independent; contexts stand in certain logical relations 
to each other; namely, one may te a sub - context of another. This 
is want in the sense that a stack frame of a language processor 
is a sul-frajne of the frame beneath it on the stack. There is no 
subset relation between a context and its super-context; rather, 
items may be present or absent in one independent of their status 
in the other, much as seme variables are rebound in a stack frame 
and others retain their old status. In the Conniver data is.se, 
all items have the same status (present or absent) in a context 
when it is created as they did ixi its super^context; each item 
retains that status until it is overriden by the user, for now, 
tl e reader cay assure that any such re-specification of status 
within a context is not done in its super-ccntext; hence, 

resettine a context to its super-context (the analogy with 
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returning iVon a stock frame is oveivhelciniJ riuces everything 
d^nc at the lower level invisible. We shall soon see examples of 
.hi:, 

A typical Conniver program generates a tree of context- 
frames , each branch cf which constitutes a separate context. A 
user is started with a rlo^l context , a list of the one rlobal 
context frare , with the glolal variable C0JJ1EXT pointinc to it. 
ADD and REMOVE work on the data base which is the value of 
CCIJTEXT (tut car. be given an optional second argument to indicate 
the.r context explicitly). The context can be "pushed down" with 
the function PUSt^CCKIEXT, which sprouts a node froa any context, 

adding a new context-frame. The value returned is a fresh sub- 

ccntext of PUSE-COJiraE's argument. (This structure is presented 

uith more rigor and detail in the first paragraphs of Chapter 3-) 
As a first example, let us consider a function PORCEUUc, of 

two arguments, ILAYIfi and SQUARE, which has a non-KIL value only 
if PLAYER can force a win on the next move cf a came of tic-tac- 
toe by playing in square number SQUtRE* (JORCEkTW is obviously 
only a fragment of a complete tic-tac-toe program.) To represent 
situations in this cane, I choose the presence cf an item of the 
fonr (HAS x yj to mean player x (= naught (0) or cress (X)) has 
put his rark in square y; if the item (IREE x) is present, it 
neans square number x has no mark in it yet. 

PORCEklL, a Conniver CEXPR analogous to a Lisp IXPR, is 
defined with the function CLEfUK as EXPf.'s are Ly DEPUxI. CLEfUh 
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alluuc cere sophisticated variable declarations than Lisp (;.ee 

"Using Conniver," below); in particular, every CEXPh has a body 

in which auxiliary variables (celleu PRCC variables in Lisp) cay 

be bound, and statements labeled with atoms. Equivalent bodies 

are civen tc every COliD clause and PEOG. There are no ta^s in 

the exacple which follows, but there are auxiliaries to be bound, 

as signalled by the keyword atom ■ASP. 

(CDEFUK rORCEVJlfi (PLAYER SQUARE) 

"AUX U ((CObTEXI (FuSfi-CGitfLXT COiJTLXT))) 
ADD '(HAS .PLAYER , SQUARE)) 
REKOVP '(IFEE .SQUARE)) 
IJUCEHGVE (OTHER PLAYER)) 
RETURJ. (TRY-1.EXT (Ul^iOVES PLAYER) KIL)) ) 

here, "AtiX" specifies that the variable COM3EXT is to be rebauno 
in the frame of rORCEUIK to a new sub-context of its old value 

(h : . 1). 

»{ ^ 





Figure 1. 
3 very iten in the old context retains its present or absent 
status in the new bindinc, but new ADDitions and RBiOVals apply 
only to the new context-i'rajre. t'hen this function is exitec, 
Cl.KTLXT's old value will be restored, and the new sprout and all 
its items will eventually be garbage-collected (if none of the 
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functions called by IGftCEWIi. saved a pointer to one of tnec, of 
course ). 

lORCEtflK operates by MHiftfaflwe? tte-t PLAi'EK has square 
SQUARE, end that the square is no lcnger free. It then ica^ines 
the other player (OTHEE (X) = 0; GTEER(O) a X), Baking a Eove* 
It does it with the function (HAKQiOVE player), which finds and 
1 akes player's test move in a situation* (Iresunably fCFiCEWIJi is 
itself a subroutine of UAXEKOVE.) The last line of the program 
then checlcs if FLAYER has a winning move, in spite of the other 
player, returning KIL if not; the system function TKY-JiEXT is 
expected to return a winning move froo the list proposed by the 
usei function WIItfiOVES; it returns its second argument if the 
list is empty. ICRCEWIK RETURIfe its value, and rebinds COiClEXT, 

freeing the square SQUARE. (The RETURH could have been onitted; 
functions, like COlit 1 clauses and PKCC's, return whatever value 

tler'r last lines produce.) 

WIIJI-'lOVIS is a generator-function, which interacts with a 

possibilities list , a very inportant data type in Ccnniver. 
Ccnniver is designed to ease the burden of writing probleo- 
solving progress, cany of which search through a problec-spacs 
network defined by a list of possibilities (solution plans, sub- 
goals, etc.) at each node. Gamfr-playing programs cooe to Eind 
iccediately, but the sane type of search occurs in programs 
designed to solve problems in language, vision, and theoret— 
proving. 
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Since the Ccnniver philosophy is that program design is the 
user's responsibility, it allows anything to be a jiossibility in 
such lists, and encourages the ur,er to play with thee, however, 
there are system possibility types (such as those Generated by 
data-base searches), and system functions for inserting and 
extracting possibilities from possibilities lists, TRy-kLXl is 
the major function for extracting then; in the simple case of 
\ inning moves (here, just the numbers of the squares PLAiEJt can 
plry in to make three marks in a row), it pops off the first 
possibility and returns it. (for a detailed account of the 
format of system possibility types, and what 1K1-NEXT does vith 
each, see the next chapter.) 

The system provides the function CBEfXSBl for defining 
genera tor- functions, routines which add possibilities to a list 
being considered by ether routines. A renerator— function , cr 
generator, is like an ordinary program, except that it is 
expected to return a list of the possibilities it has discovered, 
i.hich Eff-UQCT uses as described; in this way the generator 
communicates the values it wishes to return. In the simplest 
Gas , the possibilities are actual values; HU-I-EXT pops off and 
returns the next one, removing it from the possibilities list. 
Vh& there are no more values, TRY-JXXI evaluates its second 
argument, and returns it. Kence the construction (TEX-KEXT 
(UIKKOVES PLAYER) IaL) means "the first winning move, if any, 
else KIL-" 
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The generator V.1HK0VL3 itself might bo defined with Ci>LiG£i. 

as follows: 

(CIJPGEK fcTUiOVLS (PLAYER) 

"AUX" (SQUARE! PI SQUARES P2 X) 
(CSE1C PI (FETCh '(HAS ,HJIYXR ?£QUAKL1)J) 
:0UTERLCOP 

(IRY-KEXT P1 '(ALIHJ)) 

(CSETC E2 (IELCH (HAS ,1LAYEK ?SCUAKE2))) 
:INI.EELC<JP 

( TRY-NEXT P2 '(GO 'OUTEliLCO. ) ) 
CCQHD ((LESSP SQUABE1 SQUARES) 

(COKD ((CSETQ X (THIRI-IN-ROV SQUARE1 SQUARE2)) 
(CCiv'Xi ((PRESENT '(IREE ,X)) 
, * (nOTEX)) JT )J ) 

(CO 'INWERLCCP) ) 

(Notice that U AUX" variables not assigned an initial value are 
left unessi£ned, not cade ML as in Lisp; referencing such & 
variable before assigning it is an error.) 

Since WINMGVES is a generator, special data structures will 
be set up when it is called. These include a binding of a 
variable called PROPOSALS that tfXHHCVES expands from its initial 
NIL value using the function NOTE. NOTE makes its argument a 
proposal by pushing it onto the PROPOSALS list. When UHflftOVES is 
ihrtugh with the list, it uses the function AE1IU to put it into 
ti'O proper format (see next chapter), and return it. A later 
car to TRY-NEXT which inspects it will use it as a possibilities 
list. Since ADIEU reverses PROPOSALS before returning it, the 
proposals will be in the order l.OTEd. 

To understand VIKKOVES, other details nust be explained: 
(1) (FETCH pattern) returns a rossitilities list whose 
elements are item i.ssiii lilies, derived free all the items 
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present that natch pattern. (This is oversimplified; what fcuch 
possibilities look like, how matchiii£ works and wliat other 
possibilities can be TElCHec will be explained later.) tliiiXVES 
generates a possibilities list 11 specifying all the squares 
PLAYER owns, and regenerates it as 12 each time around OCIU-XOOK 
(Uo prizes are offered for a more eificient implementation cf 
this generator*) 

(2) When TRY-NEXT finds such an item possibility in a PIIC11- 
Eenerated possibilities list, its action is to assign the 
question— narked variables in the PITCH'S pattern to the values 
that they Batched in the item. Kence the statements ta^ed 
IHMRLCCP and GITERLCOP in klHHOVES set SQUARE2 and SQUARE1 
respectively. Notice that atoms used as labels must be flawed 
with ": tt (which turns them into expressions of the form (CTAG 
atot ) ) • 

(3) TKIfJS-Il^-ROW returns the third square in the row, column, 
or diagcnal of its two arguaents, or JUL if they are not 
collinear. 

(4) Por each distinct pair of coliinear squares owned by 
FLAYER, if the third square is free, then it is a winning move, 
and is ICOTEd. (The function (PRESENT pattern) returns I if there 
is an iter catching pattern present in the current context.) 

Thus the possibilities list returnee by this version of 
YflKKOVES includes all winning moves* (The (LL££P SQUAEL1 
SQUARE2) insures that each is found only once.) 
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Such a way of £t-neratin£ objects is not always the lest. It 
nay be, ior eaacple, ouch mere expensive to generate each ore 
t>» bo try it out. Alternatively, the generation of successive 
possibilities ciay depend on what the calling function did \/ith 
tie previous ones. Or it cay sirply be that the generator i&s DO 
id* a how nany possibilities its superior wants. (i»cte that 
TORGEtflEi is interested only in the first.) 

What is needed is a way of returning soiie of the 
possibilities while caintaining the cenerator in existence ior 
further duty if required, Ihe way this is oone is with the 
primitive Al-REVCIR, which behaves sonething lite AHEU,but 
pushes one further catuiD onto PROPOSALS before turning it into a 
possibilities list. The new datun is a ta^ to the point juet 

inside the AU-REVOIfi in the generator. The POSSIBILITIES 
returned, therefore, includes a pointer to the generator's 
activation. When ILY-iiEXT encounters such a thing in a 
possibilities list, it GOes to the tag, reawakening, in effect, 
the generator's process, including its bindings and context. The 
generator can then note new values and repeat the AU-REVOIFi, or 
do an ADIEU, either of which this tiae returns its PROPOSALS to 
TRY-KEXT after converting it to a possitilities list; TFiY-i.TXT 
then splices it into the front of the possibilities list it 
already has. 

A version of b*IU;0VE3 more congenial to use by IGRCELTti, and 
other functions that do not necessarily want all the wirxiiy. 
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novec at once, differs little from the clci in appearance, but 
ouch in effect: 

(cnrcEK rajfOvxa (plahjo 

*AUX" (SQUARE! PI SQUAfti2 12 J.) 

(cseic pi (puck '(has ,haxeh vscuarli)}) 

:OU1EFJ£OP 

(TRX-KEX1 Fl '(ALIEU)) 

(csnc P2 (iiick '(has f n.Aymi ?£quaki2))) 

iIHhERLCGP 

(Titf-KEXT P2 '(GO 'OLTERLCCi)) 
(COKE ((LESSP SCUARE1 SCUARE2) 

(CC;;d ((CSETQ X (TKIRE-IK-ROtf SGUAKE1 SQUARE2)) 
(CGHD ((PRLSEIJT '(1REE ,X)) 
(MOTE X) 

(AU-REVOIR)) )) )) ) 
(GO 'IHKERLCCD ) 

The only difference is the introduction of (AU-EEVOUi) 
following (fcOTE a). (This could have been abbreviated (Al-fcEVOIfl 
X).) However, now a call to WIHMOMS returns a H;0?GSALS with 
just two elements: a winning move and a tag to the end of the AU- 
REVOIR. 

If the tag is ever COne to (by IRY-fcEXT the second tiae it 
tries to pop off a winning cove), AL-REVOIR will do a return in 
WIKKOYES and execution will proceed with (GO 'IIJ^RLOOP). ihe 
effect en TRY-2JEXT will be that it will ciagically cone up with 
yet another winning cove ana tag. Only when all winning noves 
have been generated can WliikOVES do an ADI£U f which leaves the 

possibilities list enpty and causes TRY-HEEI to return its tecond 
rrguaent. 

These two examples do net exhaust the i/ays in which a 
generator nay interact with a possibilities list* for 
sophisticated problems, it will air est certainly be necessary fcr 
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( eneratcrs to inspect the KL«SI1ILI£IE£ bound ia, the flace pf 
TRY-KEXT, falter sore of then out, add properties to theti t).at 
the program Icokinc at then should loiow about, or even take 
control of their generation by setting enpty the POSSIBILITIES 
bound in the frame of the upper TRY-HEXT and itself calling IRZ- 
;E-' on each of the possibilities, in order to accomplish seme 
particularly complicated filtering. The functions CET- 
KJSSIBILITIIS and SET-PGSSILILITIES enable a generator to access 
this binding of the list. Clearly, in order for a user's prosrao 
to edit a possibilities list, he oust .know the formats of the 
various types of possibilities; these are £iven in the next 

cha ter. Communication the other way, froc the user of the 

I e\ erated possibilities, is cade possible by an optional nessage 

argument to TRY-IJEXT that it sends to the generator, which is 
returned, ir* the generator's activation, as the value of AU- 
REVOIR. All of these features are described in detail in the 
appendix. 
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11j ?'ry Control Structure 

hopefully, the example I have been pursuing lias made it clear 
that Conniver is just Lisp with primitives for 6ealin£ vith its 

own control structures in one way or another. Conniver, leident 
as it is about ta^s, function closures (HUJAhGs in Lisp), arid 
environments, allows processes to interact in many ways* 

Conniver treats control environments as data types called 
iraros * Lach carries Kith it VSri&tCLe bilttittlljgSj a co/.ticl 
environment stack, a saved state of the Conniver interpreter, 
and, if CONTEXT is rebound in it, a data base context. An 

internal pointer to such a fl-arne is an unprintable object which 
we refer to as a u fr,' J or internal frame- A user-manipulated 
frame is a structure of the form (*IRAME fr). A tag is a frame 
and a "program counter , u of the form (*TAG tody fr)* Ta££ of a 
sort are produced and used implicitly with AlMiEVOIE' and Tfll— 
i E . ; the user can generate thee explicitly with the function 
jAC of one atonic argument, that returns a ta£ to the piece of 
FROG, COIiE, CEXJfl, or CEItERATOR labelled with that at a. Tor 
example, the following toy program prints out J00 EAR: 
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(CD'FUiJ PFJMFCCIAK <) "AUX" (PLACE) 
(COLT. (<C£ETC PLACE (20I/IL)) 
(CO PLACE)) )) 

(c.;ruii zowjx 
(fkiet 'tec) , 

(RETURN (TAG PRIKTPAR)) 
:PMHTBAB 

(rRIKT *1AR) 
ML) 

(PIII.TPCOEAR) 

and returns MIL. (iiote that GO always evaluates its axcucer.t, 

and expects an Eton or a tar.) 

Ta£S and frames are useful for tany purposes. Relative 
evaluation , Using the Conniver function (C£VAL expression 
environment J can take a irace or ta£ as its second argument. 
Junctional arguments can be generated with the function (CLOSURE 
function) which generates the closure cf function in the current 
frame, an object that behaves like function, but evaluates its 
iree variables in the frame now associated with it* A closure is 
of the forn (*CLOSUEE function fr). 

This flexible control structure can be used to provide an 
inticiate association between a tree of probleD-investigatinc 
Ccnniver processes and a tree of contexts. In particular, as in 
Planner, procedures can be invoked fcy the addition or reucvai of 
an Stem to a context, by virtue of fcein£ linked to a pattern that 
matches the item, luch date case-sensitive procedures are called 
ili'iil ^^r:> 0I : vI X: - \-^\cn:o or ii-ru-^vsri (cr i i-i.ecncd , ciisccsseo 
below). When an itec is adced (reocved), any il-addeds (if- 
remeveds) whose patterns r^tch the item are invoked, When a 
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method is invoiced, a new frame is created for it f its vari&tles 

are bound, and its pattern is Batched c^sinst the itec. If the 

xj.tx h succeeds, execution Levins at the front ol the if-aducd*s 

(if-remeved's) bedy. Jcr example, the (anonymous) method 

(:F-ADDU) KIL (KAS 7KE0 ?5C;LAKEV , 

("AUX U fWfcO SQUARE) (REHOVL '{IKEE ,SUUARL)))) 

With naite KIL, pattern (KAS ?UhO ?SCUARE), and Lody ( l 'AUX'\..)» 
automatically erases (IKEE square) when it is asserted that (KAS 
someone square). Its use as a bookkeeper could save a line in 
the function FORCEWIH. 

A method is itself a data-type stored in the context- 
structured data base, so it may be present only in the contexts 

tie user specifies. Methods are ADLed and REKOYEd just liite 

iteis, and like items, indexed in the data base by their 

patterns. Ihe function IP-ADDED (U-REEGVEL) creates an if-added 

(if-removed) method with the pattern given by its first argument 

and the tody given by the rest of thee. The above nethod can be 

put in the cuiTent context by 

(AEJ (IF-AIEED (KAS ?WHO ?£QUARE) 
"AD;" lyBQ SQUARE) 
(REKOVE (IEEE , SQUARE)) )) 

and removed by REMOVing an object L£ ^to the one added. 

This EG-restriction means that an attempt by a user to re- 
read and ADD a file full of such anonymous methods (say, after 
editing a bu£ out of one) will put equivalent copies of all of 
thee in the data lase twice, all to be called twice when needed. 
To avoid this prccler., an if-added (or if-reixvoa ) can be 
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associated with an atopic name; thus 

(ADD (II-ADTEL US-IREE (HAS ?WhO ?£QUAhE) 
"AUX M (KHO SQUARE) 
(RHiOVE '(1REE , SQUARE)) )) 

causes the aton KAS-fREL to be associated with the Lethcd (under 
the indicator 'tlTTICD), and to be passed around by the indexing 
routines. Ixecutinf the abcve expression a seccnd tine will now 
i ause the method to be reconstructed (in case it had bugs in its 
previous incarnation), and associated with KAS-IREE, but not to 
be re— indexed, because the atom is equivalent to the method in 
the eyes of the systec, and therefore already present. In fact, 
if (IF-ADDED HAS-FREE. . . ) has been executed, 

(ADD 'HAS-HiEE) 
is equivalent to the ADD above. 

The third method of data base-control structure interaction is 
by use of if-needed methods , which cooperate as intimately with 

MTuH as if-addeds and if-re&oveds with ADD and REMOVE. Often 
the e is a class of data itens which are to be regarded as 
"present n in a context, but on the basis of Gone procedural 
criterion rather than by virtue of actually being there and 
1 ETCHabLe. An if-needed can be used to associate such a 
procedure with the pattern of a typical iten of the class. Any 
if-neededs present in a context will be found by PUCK, if their 
patterns match its pattern argument, and stuck at the end of its 
possibilities list. They are invoked by IfiY-iiEXT when it comes 
to then; their auxiliary variables (signalled s& usual iy N AUX a ) 
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are bound, and their pattern varieties assignee by a natch, li 
it succeeds, execution lef-ins in the nethcd, which tchaves like a 
feneratcr function With respect to the possibilities list II. 1- 
i.E is woriing on. 

Ivithin an if-nec;ded method, the function Ij.£TArtCE of no 
arguments returns an instantiation of the method's pattern, with 
all variatO.es eiven their current values* Then (BCKEE (IuSV/iiCE)) 
(or sicply (KCTL)) causes such an instance proposal to be added 
to FKOFCSALS and ultimately (as an item possibility) to 
JOE; IEILITIE£, thus sinulatine very nicely the presence of that 
instance as an itec in the current context, ALIEU and AU-REVOIE 
wort in the sane way as before. 

For exacple, to express the idea that all dwarves are 
vicious, in such a way as to insure that FETCH lines all dwarves 
when it looks for vicious persons, one eight execute 



(ADD (II-KErBED VD (VICIOUS ?X 
"AUa u (X (F (1ETCK * 



:LCOF 



TRY-JOXT F '(ADI3J)) 
Al-EEVOIB (liJSTAiXE)) 

GC "LCOtO )) 



DtfAEE ?X)))) 



This cethod noles one vicious dvarf each tixe XhY-NEXT is called. 

The discussion has brought us round to proposals and 
possibilities a^ain, and it is worth stopping; here to explain the 
foxrat and contents of their lists. 

While in a generator (including an if— needed method), 
iu.O.GSALS is a simple list, started at ML the lirst tii,e it is 
bound and every tir.e the generator is re-entered via en Au-I.EVGIR 
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tag* The cererator pushes proj-osalc onto this list with aifxEp 
(HUE x) being equivalent ir effect to (CSE1<* HGK£ALS (CQL3 x 
jrCLOfiAIS)'}. 

The system supports only one special type ol proposal, that 
produced by Il.SlALCL, which is an oiject of tlie fort (*IiXw 
(instantiated-method- pattern) resulb-oi-&atch) , where resulwof- 
catch is an association list (as described in "Cn Patterr*- 
Directed Invocation," below), which specifies the values of the 
variables in the calling pattern that will sake it LCUAL to the 
present instance* Instance proposals are added to PROPOSALS as 
the non-special kinds (simply called values ) are (but note i.ill 

not admit them to the list if result-of-catch is ilOKATCh). lor 
example, if the method VE finds a dwarf named HlLfcOUS, the 

instance proposal 

(*IH*i ((VICIOUS KlUiOUS)) ((X tilUiCUS))) 

i ill be created* 

A generator usually quits using ADIHJ or AU-REVGIR, either of 
which reverses the proposals list and adds the atom 
♦POSSIBILITIES to the front of the result before returning it. 

A possibilities list is Just like a proposals list with the 
:'!&' *FOSSIIILITIIS at its front* however, since TRY-KEXI nay 
-ft possibilities from several sources, there are more types of 
standard possibilities than proposals* The various types have 
the following forrats: 

(1J (*IIEft iter^or-sinulated-iten result-ci-Eiatch) These are 
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produced by FLTCJi (from the current context) and fey if-needed 
methods (free thin £ir, using IKGTAKCE)# The wry to tell if the 
item is simulated or not is to use the predicate REAL. (2ee 
"Hairy Ista Structure, u below. It should be noted that in Loth 
CBSiSj the iten is the it eg. ctetum associated with the list 
structure mentioned at the beginning of "lasic Conniver," not 
that list structure itself; ((VICIOUS IOLH0US)), not (VICIOUS 
KlliiOUS). In terms of the data structure, a simulated itec is 
just an absent one; the next chapter must be read to understand 
this fully*) When TRY-liEXT sees an itec possibility, it returns 
tl e itera-or-s inula ted-item f besides assigning the variables as 
directed by result— of —match. 

(2) (*KETH0E pattern method) These are produced by FETCH 
(pattern is the lETCC-pattern), but there is no reason a 
generator cculd not COWS one up as a value proposal. 

(3) (*CEKERATOR fona) TRY-IiEXT evaluates fcrni when it comes 
across one of these; it expects the value to be a possibilities 
list, which it splices into the one it has in place of this 
possibility, .just with »KETHOD's and *Ab^REVOIR's, Form is 

usu- Uy (generator...). 

(4) (*AU-REVGIR body fr) (ton't try to print one of these.) 

Such a possibility ciffers from a tag to its body and fra^e only 

in having *AU-REV0IF, as its flag instead of "TAG, but don't try 

GOirg to one, either; only Iftf-IiEXT is alloved to do that. It 
should be clear how these get into proposals lists. 
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(5) Anything else is a value , which TRY-iUJ^i returns when it 
pops it off a possibilities list, as in FQliCHCi*. 

Having described the "internal syntax" of UM generator- 

possibilities interaction, I now return to consideration of 

control structure, in particular, consideration of the 
fundamental operations on frames, I start with the observation 

that methods may have closures just like functions and £enerators 

do, and these, too, can be added to the catar-fcsse. If such a 

cethod is invoked by a data-base chance, control will be in a 

procedure with an access lint that differs froc that of its 

caller (like functional arguments in Lisp). This raises the 

possibility of a process in an old environment being awakened by 

the addition of an item to its context, or the removal of one 

from it. In fact, the function HAKG can bring exactly this state 
of affairs about. (KAKG is not a Conniver primitive.) (hAWJ 
release expression) evaluates expression (typically a transfer or 
return), but only after ADCing a method closure that icplements a 
test for the release condition. This condition is of the fcrm 
(IP-ADDED pattern) or (IF-REKOVED pattern). If an item matching 
prtiern is ever added (or removed, as the case E.ay le), liANC 
returns as its value the frame of the process which was 
interrupted while adding (or removing) the lten, with the side 
effect cf assigning the variables of the pattern. 

Tor example, 

(liAiCG '(IF-ADDED (Uli ?FLAY£H)) '(GO 'iOO)J 
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poes to :ICC, but execution will require with a return iron iJdiG 
if anyone adds (KIM someone) to the date base, cud ILAYIit will 



have gotten value someone. 



HAaG car: be de fined as 



(GDEFUfl HAKC (RELEASE EXPRESSION} 

"AU" (VALRET (C (CCIJIKOL))) 
(ADD (CLOSURE 

(CEVAL (COiiS (CAh RELEASE) 

(COLS (CAER RELIASE) 

V (wAUX» ((J (iRAfaL)}) 
(CSEIQ VALRLI 1} 
(GO 'HAfcGREI) )))))) 
(CEVAL DJREESIOB C) 
:KAGRE1 

(RETliRH VALRET) ) 

jy tdding the CLOSURE of the nethod, the HAivG is assured of the 

ccir.inued existence of its activation* When the pattern is seen, 

the Eethod sets VAUIET (in the environment it was closed in, 

naturally) to point to its (the method's) own frame, which has a 

control pointer to the frame (of an activation of a subroutine of 

AID or REMOVE) that invoked it. Then it GOes to KALGREr. The 

atom KAfiGKET is searched for in the access fraoe of the closure 

(i.e., the fraiae it was closed in), the correct label is found, 

and control is suddenly back in HAiiG, which returns the given 

frare. Notice that, having added to the current context the 

closure that does these marvelous things, HAKG evaluates 

(CEVALuates) EXPRESSION in its (KAKG's) control frare, the irajae 

of its caller, which is what the user presuiLably intended. 

HAitC thus exploits the iact that every frame has two superior 

frar.es it joints to, an access iraae used for free variable 
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evaluation and ator- ta£ searchir^, and a control super— iraiae that 

control is expected to return to. Usually (as in Lisp), they are 

identical, or the access pointer points a Tew frames above the 

beginning of the control chain, to the last Jraie where variables 

were bound, lut there is no reason for thirds lo be so prosaic. 
Several functions have been provided for use in tanipulatinc 

these objects. The function (JKAJ1E) returns the current frame, 
one level up fron the frajne of the invocation of FRAME* (On the 
Lop level of a CEXPE, this will always be the frane in which its 
local variables are bound). (COKSiGL frame) and (ACCESS frame) 

return the control and access pointers of frane. The CGiiTftGL and 
ACCESS of a tag or closure axe legal also. (SE1ACCESS franiel 
frare2) end (SISCOKIEOL framel frame?) reset the appropriate 

super-frane of Xreme! to be frone2* 

Closure and relative evaluation are ways of treating fraj&es 
as access environments. By EXITING a frame (with (DCIT value 
frace)), the user utilizes the control functions of frames. The 
following fragcent of code is illustrative: 

(R OG "AUX U (x v;ayout) 

(CSETQ V/AIOUI 

(kai;g '(ii-added (?x EERC)) '(GO 'USEtULWORK)}) 
(PBItl? (SOME OF in EEST IKIEiiDS AR£ IERCS)) 
(EXIT T WAIOLT) ) 

i.hich GCes to : liSEFL'Ll.'ORK when executed, but prints its cessase 

if .anything EEF.C) is ever ADDed to its context. IVAl'OUT, for 

control purposes a sublrajne of ADC, is then returned iron to 

elLTav the AID to proceed normally. 
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When no frame value is £iven, EXIT crSU, 1'rcm the coat 
immediately enclosing CCi,*D, FKCC, or CEXJR. RKlURii bypasses 
CL.X, so is often cere convenient. 

In these teres it can be explained how TKY-i.EXT interacts 
v:ith various generators; a generator is an (otherwise oruin&ry) 
function with H.OSOi-ALS bound in it by the system, and e way to 
tell, iron the deepest AU-RLVOIR tag into it, where its top frame 
is- ADIEU and AL-RIVOIR help it to manipulate and return the 
proposals list, but (RETURi. (COKS '*P0SSIEIIITIL5 '100)3 would 
work just as well as (ADIEU 'ICO). The trick is in TRY-JJEXi; 
wi e; it finds an AU-REVOIR tag in a possibilities list, it 
replaces the control link in the top frame of the generator 
structure to point to the new TRI-HEXT, and just goes to the tag. 
linding the top frame is very simple; within any generator 
activation, "GBXRASGR is always bound to it. 

Please note that there is only one type of irame, suitable 
for both access and control functions. Any frace can be used for 
relative evaluation, or can be exited; Ihe user can do relative 
-valuation with respect to the same tag he later GOes to. Other 
examples of the dual function of frames are in GET-FOSSIEILITLES 
eu'd SET-POSSIEIEITILS, which operate by using the control link 
of a generator as an access environment for the variable 
FCSEIEIIITIIS. Shis works because of the fact that after its 
first call a generator's control link points to a sub-frame of 
TRY-KEXT, where jOS£IF.TT.TTILS is bound. 
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This control structure is intended to be manipulable by the 
lie;. KAi.G, for example, is written in ConrJvei, not Lisp. The 
CLrtrol structure primitives of Planner can be written fairly 
simply in Ccnniver as follows: 
(CSETQ FAILURE-STACK JilL) 



(CDEFUJi JAIL () n AUy." (11) 

COin; ((t.ULL FAILURE-STACK) (FRIKI 'JAILLH) (GO EAR-1))) 

CSETQ T1 (CAR FAILURE-STACK}) 

CSETQ FAILUIil-STACK (CIS. FAILURE-STACK)) 

GO T1 ) ) 

(EAR-1 is explained under "Using Conniver," belcw; (CO EAR-1) 

gets a program to the top level.) This version of planner 

maintains a list FAILURE-STACK of environments to fail Lack to. 

Ti.e list is tamen apart by JAIL, which pops off the next element 

and GOes to it. The list is built by FAILSET: 

(CLEFUK FAILSET (T) 

(CSETQ FAILURE-STACK (COhS (TAG T) FAILURE-STACK)) ) 

Hote that since FAILURE-STACK is an ordinary Conniver variable, 

there cay be local bindings of it, hence a complex structure of 

failure stacks bound at different levels. 

(Ci'.FUK COAL (PATTERN) "AUX" ((LATA (FETCH PATTERU))) 
:GOALF 

iFATLSET 'GGALFi 

(TF.Y-KEXT DATA *<PHGC (CSETQ FAILURE-STACK 

(CDR FAILURE-STACK)) 
(FAIL))) ) 

This version of GOAL obeys Conniver conventions for data lase 

search, pattern forest, etc., but behaves lite the Planner 

version in that it responds to a failure by 7Rl!in£-the-liEXI 

Batchinf oatuE unless there aren't any, in which case it 
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continues the failure. Since this COAL woris with if-needeu 

methods instead of consequent theorens, a Planner versicri cl iiOlh 

rust be invented. It loots like this: 

(Ci'.IUK TKECIE () ^^ 

(FAILSET 'TKi.UTEF) 

(retuu; (IJOTE)) *~. ., - . 

" (CSETQ PROPOSALS (CDS PROPOSALS)) 
(JAIL)) 

THi.vTE behaves exactly like NOTE of no arguments., except that it 

excises its proposal from the proposals list and continues 

failing if a failure hits it. A prograc executing (THRCTE) 

(A1IEU) can use the abbreviation (SUCCEEL): 

(c:\tw succeed o , 
(failset ^cceelf) 
(axieu (ikstalce)) 

:Si.CCEELT 

(CSETQ PROPOSALS (CDE PROPOSALS)) 
(FAIL) ) 

The two retaining functions simulate ASSERT and ERASE in that 

the r effects are undone on failure: 

(Ci'PUJJ ASSERT (SKELETOK) 

(FAILSET 'ASSERTI) 

(RETURiJ (AED SIOTETOiQ) 
:ASSERTP 

(KILL SKELETOK) 



(CDLFUU ERASE (SKELETOil) 
(FAILSET ERASE*) 
r.ETbrui (REMOVE SKELETOit)) 




(IjISERT SKELETOiO 
(FAIL) ) 

y i T.I and IUSERT are versions of RliiOVE and AIL thich do not 
search for and invoLe if-recoved or if-added rcethods; here they 
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are usee to undo the effect of AESO.T and EhASfc before failu-e is 
allowed to propoxate,. 
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Kairy D et £ structure 

hopefully, the t.ser Jia^ understood the references to data 
i as- fcanipulaticn so far. In Tact, the ran^e oi operations open 
to him is much larger than right be supposed. 

In this chapter, I an* ccing to build up a^ain the notiui, of 
context, starting this tine with meaningless ,J ira£Hients" of world 
models called con text-f ra pes* Contexts are implemented as 
ordered branches of a tree of such frames. A context-frame (o- 
fraine) is used to define changes to a world codel as one takes as 
his context longer and longer hunks of a branch of the tree, 
starting from the root; this secantics is exactly reflected in 
the definition cf PUSK-COIJTEXI, which gives a prograc one core 
frare in which to indicate such changes. 

To be precise, a c- frame's sole function is that every catuir. 
in the data base may be thought of as realized, unrealized , or 
unsjccified by every o-frame; for now, these frames have no 

relevant internal structure; they night as well be buckets lull 
of nentions of data as "realized" or "unrealized. >J 

The user, of course, is building contexts out of the£, lists 
flawed with *CGiiTEXT as their first elements, iollowed by c- 
frames* In a particular context, a datum is always either 
present or absent , its status depending on search rules through 
the o-frar.es of a context, which are ordered from "Lost local" or 
"o^st recently pushed," to "cost global." 
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figure 2. 
To detemine the status of a datum in a context, find the 
first (cost local) c-frane cf the context where the datum has 
specified status, and use that status, either realized or 
unrealized, to specify its status in the context as present or 
absent, respectively. If none of the c— frames define a status, 
it is absent. lor example, in Fig. 3, if the narks "■*" and "-" 
i:dicate reality or unreality of a certain datum in the c— frames 
next to then, the examples of contexts built from these frames 
show under what circumstances a datum is present: 
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Kotice that a datum nay have unspecified status in most c-fiames, 
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I illustrate these search rules with examples of perhapt the 
nost primitive oata in this schcLc, tho^e of tyj-e object, created 
with the function G1JEC1** Objects are viewed bj the data-U.sc 
nanacors as arbitrary list structures whose only systeii*- 
Eaintaineti properties are presence arid absence. The pro^ra^mer 
can use these properties to model any secsantic features he lilcec. 

For exarple, a vision program, as it reconstructs a visual 
scene from a vidissector iiaage, must consider core than one set 
of possible real-world objects, and decide what is really there 
on the basis of which is nost consistent with the evidence. This 
world eight be modeled as a list of Conniver objects, only some 
of which are present in any context- Thus, an object proposer 
eight succarize its conclusions by adding a new data object to 
tie list K)£SI£L6-0£JECiS: 

(CSLTQ K)££IELE-CEJLCTS 

(CCIJE (CSETC LEW-OEJECT (OUECT '(R4 R5 ($))) 
P0EEIBLE-0EJEC1S) ) . 

This forn creates a possible object, iiEU-GUECl, censidered to 
censist of regiora 4, 5, and 9- (A realistic cata structure 
would undoubtedly have to contain ncre inforKition.) This object 

looks like (*0£JECt (R4 R5 fc9)) f ana has structure (R4 E5 RS), 
which the system ignores, hew objects are, of course, absent in 
all contexts. 

To rcahe this datum present in the current context by virtue 
of realization in its top c-frene, one executes (REALIZE KEfc- 
OEJECT); to cake it absent (by virtue of unrealization there), he 
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xeiutes (UIJILALIZI. KEtf-GUECT).. The predicate ItEAL returns its 
ar^ucent if it is present, or J3I< il it is absent; U.REAL, the 
opposite- (These predicates test lor presence and absence in 
tie current context, and thus consider all c-frcues accoruii-s tc 
the search rules given; they do not merely lcoi at the top en- 
frame.) 

To illustrate the use oi these primitives, imagine a data 

structure for tic-tec-toe as follows. Let XS be a Lisp array of 
S data objects like that above, such that (XS n) is the X in the 
square n; let OS be a similar array of objects. With this data 
structure, the predicate (JKEE square) can ts defined thus: 

(CDEPUil TREE (SQUARE) 

(KOT (OR (REAL (XS SQUARE)) (REAL (OS SQUARE)))) ) 

To put an X in square 5 (the center), for example, execute 

(REALIZE (XS 5)) 

If this is done in a particular context, the board will "have an 

X in the center" in that context and all contexts sprouted from 

it. By resetting or rebincing CONTEXT to a higher point in the 

I ranch, the "X" modeled as (XS 5) can be made to "vanish," as (XS 

5) reverts to absence* 

To suoiarize, a context is a branch of a structure of 
context- frames. The structure can be grown at its tips (using 
FcSK-COIiTEXT as described in "Basic Conniver'O, and manipulated 
in ether vays to be jnenticned. The search rules through a 
context are such that the presence of a datum is not disturbed by 
pushing new c-fraires onto a context unless it is specifically 
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ULlALIZEd. 

So far this section lias concerned itself with data objects 
vhose only properties are presence and absence- The reason for 
this focus is to isolate the search rules that define "present in 
a context,' 1 as predicated ol any datum* ana the functions hLAUZL 
sj d UKRLALIZE, and the predicates RUL and UNHEAL, that &al% the 
ccncept useful- 

In fact data can have many more useful attributes than 
presence. lirst, as pointed out, an object riay be created with 
an arbitrary structure* Por example, still another 
representation of a tic-tac-toe situation would be a Lisp array 
SQUARES of 9 objects, each having as structure its number in the 
"nafic square™ representation of tic-tao-toe (ir. which the 
j. umbers in every row, colucn, and diagonal add to 15; this would 

be of use in THIRJ>-II*-nGlO- The upper left-hand square would be 
created by (STOKE (SQUARES C) (DEJECT 2)) f ior instance; the 

object (SQUARES 0)*s structure is then "2 U ; this object looks 
like (*OEJECT 2), and, at creation tiise, is present in no 

context. 

Second, any datum nay have rr parties in any ©-frame* 5his 
feature is dealt with below- 

Third, some types of data are indexable and can be searched 
for (internal operations of ADD, REIOVE, and TESCh), by virtue 
of association with a pattern- These are, of course, itecs, 
netliotis, and closures of cethods, which are like non-indexable 
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objects in every other respect, 'ilit difference between an iter, 
and an otject is th&t an item cay be specified ly a slieleton or 
pattern {although it doesn't have tc be), but an object nust be 
centioned directly- The user should perceive the sicilarit^ 
between Aiding (KAS X , SQUALL) in lOhCLVIii and LLALlZin£ (XS 
SQUARE) in the simpler OBJECT array representation of a state of 
a gciae of tic-tao-toe. ADD simply REALIZES the item its skeleton 
represents. £oth routines, fiven indexable data arguments, make 
sure the data referred to are indexed and all relevant if-acdecs 
are called- A sicilar relation holds between RliiOVE and 
LIEEALIZE. The choice between the itea or object representation 
should be fcfcsed, aaong other things, on how the user wishes his 
data to interact with his prograiss. 

lfotice that, since ADD and miOVE are merely ways of 
referring to itecs by skeletons, using then: to handle nethccs, 
referred to directly or by race, is svnonyecus with use of 
REALIZE and UiiREALIZE* In fact, even an itec, once in the cata 
fcese, looks something like 

((HASO 4) (52 -J (0 +)) 
(see description of c-markers near the end of this section), 
v.he. e the iteis ADEed (a new list structure derived from, say, 
(iA: ,X ,Y)) is only the first element cf the actual itec aaturu 
Therefore, item data, as data returned by ADD, REMOVE, FKESLiJT, 
/■£SO:T, (TRY-KE;T (IETCK...)), etc., indexed or unindexed in the 
data base, can be RLALIZED and UinEALIZID just like the others. 
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Although itestE and objects can be arbitrary list structures, 
it is very often desirable to separate a oatun 's "essence 11 (e.£. , 
vFRLD ILOGS TOOLS)) from its "accidents," or iU> procerties by 
virtue of be in/? present in a cot text , such as 

(RtASOh (*KLD 1S-A SAL1ST)). 
Association of indicators like KLAEOii and properties lifce (IKED 
IS-A SADIST) must be relative to a context-frame. Lvery oatun is 
mentioned by a set of contexts-frames, as realized, unrealized, or 
as having properties, and associated with each such mention is a 
property list which contains pairs as shown. 

To associate indicator with property in context, on datum, 

(BPUT datum property indicator context), 
where context is optional with aefault value CGI. TEXT* This 

causes the first enframe of context to mention datum if it does 
not already (it leaves datum's present or absent status 
unaltered), and associates indicator with property with respect 
to that mention. 

(DGET datum indicator context) 
returns the first indicator- property pair found by searching 
through all mentions of datum by c-frames in the current context; 
or IJIL if there is no pair with indicator in any mention of datum 
iy context's c-fraces* Finally, 

(BKEK datum indicator context) 
does a DGET, but removes the pair if it finds it. 
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Usually one doer* not wish to reier to the ji.cn ticn of a oatun 
by ell the c-fras:es of the current context, but only to the 
mentions thtt specify realization, those createc by AED or 
REALIZE. These functions mention the datum as leiri£ realized in 
a particular c-lrarc; such a irai^e will be the lirst status- 
defininf frar.e in the context in the case of any present datw*. 
To add to the datum's properties in this c-fraj*e, use the 
function CHJT+. (If the datum is in fact absent, an error will 
cccur.) To retrieve and remove properties only from the set of 
all "+ "-inarted frar.es up to the first "-"-marked one, use the 
functions DCEF+ and EKEK+. (If they are given absent ar£UDents, 

they always returns KIL.) 

for example, if COJJTEXT is used by a procrat. to near* "the 

world as it stands now," and YEETERiEAR points to a higher branch 

(a super-context) of CONTEXT, a pro£ram cay find out that 

: unc thing was true that no longer is, and indicate its current 

status, in the following way: 

(COIU ((CSEIQ ITEM (HESLKT '(EXIST 5-CK«T CIGAES) 

YESTDOIAR)) 
(COMD ((UNREAL IOEI-i) 
(EPUT+ ITEti 

'BY-GOKE 
'CURRQ.T-STATUS 
YESTERYEAR)) )) ) 

which construction saves it from having to discover which c-fraiLe 

of YESTERYEAR it was realized in. Notice how UAL and UiffiEAl 

work with items and irethocs as veil as objects. 

As another example, I return to the representation of the 
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tio-tac-toe board as an array SQUAkLS of 9 objects. Let each 

such object speciiy the occu-p&nt or the corresicnding squart in a 

particular context as its property under the iriCicator C-CCUjAii'I; 

if it is empty, let the object be absent in that context, lihen 

irEE can be written 

(GTIFUK TRU (SQUARL) (UHREAL (SQUARES SQUAhL)) ) 

and the occupant of a square in the current context ni^ht be 

found ty 

(amd (real (squares square)) (cadr (lgeiv (squares square) 
'occupai;t)» 

which returns X, 0, or EIL. Then EGRCEL'IM coulc be written 
(CIEFUIJ lORCEt'Ii: (FLAXES SQUARE) 

"aux u ((col.text (fush-coktexi))) 
;dput+ (realize (squares square)) player *cccu?ajjt) 

J1AXEK0VE (OfliER PLAYER)) 

;TRY-EEXT (WIKKGVES FLAYER) 1.TL) ) 

If the secantics of property-list manipulators does not quite 
fit your needs, there are acre primitive functions, described in 
the Appendix, which enable you to tailor— cake your own versions 
of then. 

If the user is to understand this data structure completely, 
he should taiow the formats end properties of context-frames; each 
i.ne is sicply a list of the fore (*CFRAkE cnuo *date»), where 
cnum is a number unique to the frame, and data are the data it 
mentions; GLOLAL, however, ior internal reasons, always lools 
;ilte (*CFTiAl£ 0). A context is a list (*CGJ,XLXY "c-frames*), 
where c-franes are con text- frames in order cf decrees inf cnus , 
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the last of which is always GLOIAL. 

It is a useful leature cf context fxanes that they vanirJi 
w!en no one points to then, i.e., they are £arix-£e-collcctaLle. 
When one so vanishes, it tales every mentior. oi a datum in it 

with it, alon£ with all properties and, of course, any status 
definition, however, although the mention of the datum in that 
o-frane is rone, all other c-franec* references are intact. Thus 
one cay £U£h— COhXEXl, assign some properties to a datum in the 
new context (usinc EPUT, EGF.T, and LREM), while doine a little 

computing. If be then flushes the frame, all the propenies will 
vanish, while the datum's status regains the sane* 

The rest of this section is concerned with the details of 
system interaction with the index, £arta£e-collecticn of 
and xable data, the semantics of absence vs. presence, forests of 
the Barkers on data that define their context-sensitive 
properties, and esoteric property manipulators. Rather than 
attempt it on a first pass, you may wish merely to skip to the 
last pa^e and heed the warnings printed there. 

For those with confidence in themselves, I te£in with the 
problems raised by esoteric property-handlers. Notice that 
functions like UNREAL and REMOVE return data whose first status- 
defining mention in the current context specifies unrealization. 
To ranipulate properties in the c-fraces mentioning a datum this 
way, use DPLT-, KJE3-, and LREK-, which are almost completely 
iuJ.O£OUS to their "+* counterparts, (hence, EFUT- will cause an 
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error if the datuir, it is civen ^ E present ,) Kovever, the sitoloty 
is somewhat flared* 

The description of presence vs. absence of a datum that 1 
have given has not differentiated the properties they sl^xe and 
do not chare. In a sense, they ere equivalent; a datun:, once 

realized in a content-frame, cannot be tade absent there by 
operations at a higher level, and unrealization is equally 

tenacious. Eut "ateent" can also oean "having unsi^cified status 
in all c-frazes of a content*" V'hat are primitives like DPUT- to 
do in such cases? Cowiiver's solution is to treat o-fratae CLONAL 
as special, in that having no mention but "unrealised in GICBAI, n 
is equivalent to having no mention at all. 

This requires a detailed explanation, (tut, since in nest 
cas s the intuitively desirable thing happens, it is not very 

important that this explanation be understood.) Every datum 
keeps track of its mentions with context carkers (o-markers), 

ea^h of the form 

(cnuir status *property- pairs*) 

where cnum identifies a c-frame and status is +, -, or KII*. 

lonrally, a mention of a datum toy a o-frajue is its assignment of 

len-iJIL status or properties or both, but with (0 -) excluded (O 

being the cnum of context frame GLOLAL). This ueans that o- 

carkers of the form (52 2.TL (ICO EAR}), (0 -0, or (3 -) are 

mentions, but (*2 KIL), (0 KIL), and (0 -) are not; when a c- 

carker like one of the latter arises by the action cf a system 
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function, it is celeted froc, its datuti. The saLe liappeiiw 
{eventually} when nobody joints to the c^fraite kith a r*ari:er's 
cnuD (as it is Hushed by the fjjba^e collector)* Indexable oata 
are indexed only uhen there is at least one mention of thee by a 
livine c-frane, to &llow for tarfcece-collection of totally 
worthless data which would otherwise be protected by the index. 

This state of affairs clears the way for GLOBAL to te the 
default c-frane used by DPUI-, EGEE-, and EKQ-i- if the data they 
work on are absent by virtue of being unspecified in all c-iraces 
of the current context- 

If an exaople will help, consider this. Starting with a 
fresh data base, you type 

(CEETC 21 {RBiCVE '{LYIIOII PULLS PIC-EARS))), 
which returns, as it should, the item datum referred to, with o- 
carkers as its tail: 

((LTKDOK PUU£ PIG-EARS)). 
Its CAR is the instantiated skeleton (££UAL to it), its CDR (and 
lisi of c-narkers), HIL. It is not centioned or indexea; no one 
can tell it is there, You KEHOVEd it, right? Ihe (0 -) you nay 
have intended is invisible* How you try 

(EPU5- B1 'IhSTEAD 'LOG-EARS) 
ard out coces 

(BOG-EARS IUSIEAB)* 
t: e neu property pedr DPUT- created- But look at the value of 
D1: 
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((X3CU30H FULLS PIG-LARS) (0 I.IL (iXXr-UUiL IUETKXL)J). 
Not only th^t, but (/iLSLiit '{LYIILGi* PULLb >IG-l/itS)) will find 
Dlj it's indexed, how, typing 

(EKFli- 1/1 *IjOG-LAKS) 
t ; it tS OUt 

(DGG-EAhS IESTEAD), 
the deleted pair. I>eletin£ it has made the c-marker (0 illLj a 
non-mention, so it is deleted from the item, leaving no mentions 
of B1 f which is therefore unindexed. 1)1 looks like; 

((UflffiQK IUXLS PIC-EAKS)) 
egain. 

In this vey CLOIAL is treated uniformly as the c-frame uhere 
things aren't when they aren't anywhere else, (Ontologists take 
notice.) 

This treatment means that RB'-OVal at the top level allows 
garbage-collection of items, which, because of the tenacity of 

absence in general, cannot take place at lower levels whose c- 
Traces are still alive. Since all contexts neec such a c-frame 
at the bottom, GLOLAL oust be the last c-frame in every context. 

If the user has noticed the delicacy of this structure, he 
lill be more than glad to heed the following warnings: 

(1) Don't build contexts by any method but with the system 
functions provided for this purpose. 

(2) Eon't play with a datum's c-markers on :our own; you cay 
create an illegal mention, scramble their order, or be caught by 
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a context-frajae ^arla^e collection. Once you h£.ve a property 
pair, however, you ray safely do anythiij£ you wish to it. 
tilth these caveats in nind, the user icaj turn to the 
i t s* riptionn of the following context— building functions; 

(1) (iiLV-COhTLX'i o-frame-lisl) rakes sure the c-frar.es in its 
ar£ix.ent are in the proper order, then adds a *COiiTU(T at the 
front, returning the result. If necessary, it splices in a 

I Li: ter to CIX3tAL at the end, to cake sure it's there* 

(2) (CHtAKE) creates a o-frame with a unique cnurc, hi&her 

I I en any in use, suitable costly for use in expressions like 
(KEV-COliTEXT (LIST (CFRAliE) GLOEAL)). 

(3) (PU£K-CO]jTEXT context) behaves just like 

(LAHEDA (COKTEXT) 

(uOiJS '*COIJTEXT (COIIS (CFRAKE) <CDR COKTECT))) ), 

but its argument is optional with default value CONTEXT. 

(4) (K>r-COi;TEXT context) behaves like 

(LAT-EDA (COKTEXT) 

(COKS ''CONTEXT (CDDR CONTEXT)) ), 

but it, too, will take CONTEXT as its default argunent if it is 

applied to KIL. 

(5) (SHJCE context) adds a brand-new o-frair.e just after the 
first of context, and returns its argument, with its structure 

wad. 
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Cti Iattera-lirected Invocation 

Methods can te invoLea in association with adding items to, 
fetching items irom, and rei-ovinc items iron iht data uise. Ihe 
invi cation aeiiercs en a catch between the nethoe'e pattern *-nd 
the iter. 

The natcher usee in Ccnriver is very simple, and is biased in 
favor of taking a constant list en one side. (loATCh varpat 
datapat cataenv), where tlataenv is optional, assumes varpat is a 
pattern of a FETCH cr method. A pattern is a non-circular list 
structure with certain sub-structures that are expansions of 
expressions starting with the macro characters n ? n $ "!", ",", and 
"€'». "tvar* (which expends into (GIVEH var)) indicates a 
variable that is to receive a value during the catch; "!var" 
({A££IGL var)), a variable that must catch a variable-free 

expression for the catch to succeed; '^vax' 1 ((CVALUE var)), a 
variable whose value is to be substituted in the pattern before 

the natch berins* (Varpat variables are loclced up in (KiAkL), as 
are datapat variables if no cataenv is £iven*} "Gexpr" expands 
ini- (/4 . expr) and means "the Lisp value of expr," which is 
substituted into the pattern, gfain, prior to the natch. (See 
"Lisp and Ccnniver," below, for further information about "c u .) 
KA3tH does not actually assign the pattern variables; it returns 
an association list pairing each pattern variable that matched a 
Cgbi tant expression with that expression. If the natch failed, 
however, the atom iiCilAICK is returned instead. The matcher is 
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rulti-levol (that is, variaLles can occur below the top levtl or 
list structure), and dots are allowed in patccn.a, as (Lliiu bl£l 
. ?X). Hence, the pattern ((PfiiiS ?X) . ?KiST) matches 

UlfcElB 5AI1XK) ItfilSEDEGj 
((IKEDf PAaKDi) LfclSXLtS D1X1L} 
((IKLDS CQliE} KE SAIL), 
generating association lists 

((X JAXhEK) (RIST (KHISXLEi))) 
((X PAIHEK) (HEST (UHISILES DIXIE}) J 

((X GOtfE) (REST (HE SAID))), 
respectively. 

TR'f-KEXT takes lists generated this way (as it finds then, 
associated with iten possibilities), and assigns the variables as 
they direct. 

if-*addfcs end if-removeds work nicely with this matcher* To 
invoke one (or the closure of one), Conniver binds its variables 
and, in the method's fr-ame, matches its pattern against an item. 
Since there are no variables in itecs, all variables in the 
pattern get values. The invoker then assigr-s then and starts the 
> etl od. 

If-neededs* patterns must often be catched against patterns 
(bf PETCH's) that thercselves have variables. Invocation proceeds 
?s with other methods, tut a method variable matched against an 
expression containing question-narked atocs in the lETCh-pattem 
simply does not receive a value. If the method variable is 
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receded try "!" instead of "?", the natch fails iu&eaiatcly. In 
ifiCtf sui— patterns of the fern "!var u find theij £reatest u^e ix* 
patterns of if-needtds that, armed enly with "?'*, would iiavt- to 
la* as a first line, (COjiB {(Ul.ASSICiiEL 'var) (AT/I1U)) ), 

Notice also that TRl'-iiEXT in no case assigns ^ variable in 
the FETCE-pattem while invoking the if-needed cethed, when the 
jETCIl-pattem will be datapath Thus catching an if-needed's 

(Fa A ?2) against calling X' attern C* 100 ?x (IKHS ?i)J aoes not 
assign X, Y, or Z in either environment. (And, if the if- 
reeded's pattern were (POO A !Z), the method would not be 
executed at all.) It is only as the method finds and liGTEs 
instances, IKSTAKCE catches the FETCK-pattern against then, and 
TRY-jMSXT uses the results that such assignments cay take place, 
Since instances, liire itecs, have no variables, all FETCh-ps.ttern 

variables are ruarcnteed to be assifned by 1RY-J.EXI, (planner 
users please note,) In the example given, if the method assigns 
Z to (IEEDS GALORE) and notes this instance of its pattern, TRY- 
;E\ will arsi£ii X to A and Y to CAIX5RE when it comes across it. 
If, on the other hand, the method assigns Z to something like 
LINCOLN or (SALLYS FURS), the catch by liJSTAiiCE on the instance 
(FOG A LIUCGLK) or (F00 A (SALLYS FURS)) will fail , and iiOIL will 
reject it as a possibility, 

A word should be said here about skeletons, the list 
structures ADD and FEhOVE use to specify itecs; "skeleton" is 

de.fned just li];e "pattern," except that only "," and "t" are 

T 
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all* wed; Uiat is, every skeleton Lust exfeud into an expression 
with no VETis-bler;. 
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Ikj^r Ccnniver 

Conniver is a r emar l mte Ly friendly language to use, LecaLse 
its control structure is n ojen to the public. 11 The command 
CNVi "K typed at LEE causes Conniver to print out its version 
number, set up an initially empty global context assigned tc 
CLOIAL, and print 
1AI-1 

Tie " tt is printed cut whenever Conniver wants input. Xhe ear it 
is listening with ir-itially is EAK-1. This is not a Joke, tut a 
tar into a BEAD-CEVAL-HilJiT loop at the top level. Interacting 
vith such a loop ought to be very easy for an experienced Lisp 
user; Ccnniver will attempt to CEVAL everything typed at it, and 
will print the result. 

If input is switched to a new file (using ULEAD), masses of 

CEX_K's can be defined using 

(CDEFUK naine (*variable-declarations*) *body*). 

CiEMR's, CLEXPF/s, or something similar, are net needed because 
of the flexibility of variable declarat 1021s. Etclarations can te 

just a list of atoms, but the construction 

"OPTLQllfiL" ^declarations* 

enables function to supply default values fcr missing trailing 

arguments. Por example, the declaration (X "OEilOiWL 11 (X 

CUETEXZ) Z) specifies one required and two optional argunents; if 

Y is oissinf , it receives the value of CGKTLXT; a missing third 

argument leaves Z rebound but unassigned. 
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I! the last two eletentc of the aeclaratiwx are 

■TiES'l" var 
var is bound to a list of the rciuiinin£ ar^u^entr,, each 
evaluated. 

In ils.ee of a declared variable, the form (CUOTL var) te&y 
appear in any oi the variable declaration slots, incluuinc "KiSl" 
*var. This lias the effect of bloc king evaluation of the 
corresponding argument, or list of ar£im.ents in the case of 
TEST 11 * A 1EXPK of one argument L in Lisp, therefore, lias as 
counterpart a CU£R with declaration ("REST* 'L). 

(It should be pointed out that this entire variable 
declaration syntax was taken free HUDDLE*) 

In similar fashion, CDEEGEil can be used to create generators 
using the seme variable declaration syntax, and ADD can be used 
to create an initial context of items and methods, 

Uhen an error occurs (either a Lisp error or a call to 
1 ERROR), the system creates a new frame with the frame of the 
error as its control pointer, prints a message, defines a new 

ear, and enters its READ-CEVAL-K<Ili*I loop, printing 

lA:-n 

The function BACKTRACE can l« used to get a lucid summary of the 
t ontrol pointer chain from (JfRAIX) upwards- Variable velues can 
be inspected, furctions can be called, etc- Quitting completely 
is cone by typing (CO EAK-1), EAR-1 being the alvays-definec top 
level. To continue execution, EXIT from EAH-n. Since the value 
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ray i-e irrelevant, the Junction (MSKISS frane) lias been provided 
to exit fror. it with no particular value, 

DISIJSS coces in handy in conjunction with the "A-interrupt 
feature* To stop Conniver between elementary steps, hit "*A. 
This will cause an "interrupt," ana create a nev ear* lo restart 
tie process use (DIW1ISS); DISIilES taJres (IhAlil) as its deiault 
argument. 

If a Conniver program is in the middle cf executing a piece 
of Lisp that it called, it will correctly intercept any TX'fi not 
iau ht by EERSET's in the Lisp itself. However, since Conniver 
is written in Lisp, it is possible to mangle it by hitting "X in 
the ciddle of doing some internal Conniverish tiling, 

Sicply EISHIESing f^om an error will cause Conniver to try 
a^ain what it choked on before. If it hit a "A, that means it 

vill continue. If it cho&ed on a "X which turned off an infinite 
pri: tout, DISKISSinc will start the infinite printout again. If 

it barfed because of an unassiered variable reference, it will 
lar, again unless you assign it before LlSiHSSing. 

You can get out of Conniver at any tiise by calling STOP. 
This leaves all Conniver structures intact, but puts you in a 
lir;; READ-EVAL-FRIi.T loop, where Lisp errors dor/t generate 
aniv ying nev ears. To restart in exactly the state before 
(SSCP), call (HUH); you're back in Conniver. (RUB and STOP have 
more sophisticated uses; see the appendix.) 
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j isp and Conniver 

Lisp functions do not usually call Conniver CIXIK'e, 
CEKEKAlCB'e, ana CILX's (the analogue of ISUHt's in Lisp), 
i e- use Lisp stacfcs are far core perishable than Conniver *s 
frare-trces. (lut see the description of CLVAL, below.) 
Ci.nr.iver can call any Lisp function, though, and Lisp D-FH't., 
lEXR's, LSUtK'e, and SuIK's can take Conniver arguments in forus 
evaluated by Conniver. lor example, 

(FKIMT (TRY-UEXT P MX)) 
is perfectly legal. Lisp functions called by Conniver can 
reference Ccnniver variables free by use of the function (CVALUt 
var), abbreviated "jvar". lor example, Lisp functions should 
refer to COKTEXT as , COKTEXT. 

Since Lisp can't call CIXPR's, functions that do Conniving 
things cust be written in Conniver down to a lot level. The 
resulting slowdown cay cake one cringe, but there is a remedy . 
Any piece of pure Lisp r£y be Eade tore efficient by prefixing it 
with the "t" macro-character, and rralcing all Conniver variable 
references explicit by use of ",". lor example, 

6(TKIRD-IK-h0tf .SCUAREl f SQUARE) 
v.i-ee TKIKX-IiMvCW is an EXFR, is much more efficient than 

(TKIRD-Iii-hOtf ECUARE1 SQUARL2) 
because it expands into 

(/€ SEZBD-Xfi-jBOtf (CVALUE SQUARE1) (CVALUE SCUARI2)). 
/€ belnf a rEXFK, namely 
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{LAiiiLA (EXP) (LVAL Dff)). 
C^rjiiver always gives i'LXPh's complete control ever their 
argument evaluation, so Just hands the expression (/a .„) to 
F~-A , saving generating a j^ranc and interpreting the expression. 
T: e 6 macro is thus & way ci hand-compiling arbitrary sections cf 
cod' involving no G£XHi% GlHE&AICft's, or Cllffi's. The c ay te 
used inside skeletons and patterns used by ALL and REfoOVL, and 
jETCH; just as * t u in such a context means "substitute the value 
of a variable," so "fe" means "substitute the (Lisp) value oi an 
expression." Another use of the & macro is getting the Lisp 
value of a variable within Conniver; €CQHILXT f for instance, 
pets the Lisp value of CONTEXT, just as "," gets its Conniver 
value. (It should be pointed out here that if Conniver can find 
no binding of an atcm while looking for its C VALUE* it takes the 
global Lisp value, if any, so that sometimes £ and , do the saiae 
thl g; this h*** 5 the consequence that Conniver concludes a 
variable is unbound only if it is globally unassigned by Lisp*) 

A Lisp program, if it really wants to, can use CEVAL to 
Conniver-eveluate a fort. If it is a well-behaved form, this is 
just like using EVAL, but there are pit falls . £ome of the 
problems stem from the fact that the frame and its daughters 
generated by execution of the form cay hang around (with a JiAiiG, 
for example), after an EXIT back to the Lisp* l:hile contrcl is 
in this structure the first tice, Lisp variables bound in its 
caller ray be accessed (with 6), and in general everything is 



i*G£ &3 



cool* After it returns, however, the Idsp return point vanishes, 
along with its irate, bindings- etc., ar,d even the irane of the 
EXP: CEVAL. 

If control re-enters the Conniver structure, the new Lisp 
static-state above it will have nothing to do with the orlglrr.1 , 
God will know wtiat Lisp variables are refertnct^ble, am a return 
froc the structure's top level will have no obvious meaning. 
This is not to say that a process created in this canner has no 
use, but merely to emphasize the darters in creatine one* 
Attecpting to 6 a Lisp variable will probably find it unbound 
\ creating a Lisj-erxor in Ccnniver), and an attempt to return 
froD the control structure again generates a Conniver error 
(whi.se LAfl has as control pointer a frane created above the 
structure for just this purpose the first tiite control returned 
froc it). 

There is still another problem which is even worse. If, 
during a CEVALuation, control leaves the new* Conniver control 
structure it created (e.g., by GOing to an old tag), and never 
returns, the entire old Conniver process will be running with a 
Lisp stack slightly different frcn what it started with* In 
particular, all the Lisp frames that were arouno when CLVAL was 
called are still there, but there is no way to aetect or flush 
fher. In such a situation, STOP (see Appendix) no longer dees 
th' right thing, and the stack has teen enlarged in perpetuity. 
Enough such pathological CEVALs can cause a pdl overflow- ihe 
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user is strongly encouraged to use f.Uii end CXU? for Lisp-Ccrjrivcr 
interaction, everi if they are trickier* 

Cue pleasant thought is that cany Ccnniver l unctions arc 
actually EXFK's, or have EXI-fi versions which do airiest the same 

thing. (In the compiled Ccnniver system, ol course, these *-re 
: lE *s or lEOTfi'c, lut 1 vill continue to use the teria I2PK in 
the loose sense "Lisp function. 11 ) for example, the CZVAL yoi; get 
if you call it iroE Lisp is clearly different iron the GIST 
version the Ccnniver interpreter would fine. All functions with 
EI. versions can, of course, be called from Lisp. Happily, they 
include all the data base-manipulation functions, but the EXPR 
versions of AED, REMOVE, REALIZE, and UKREALIZE differ slightly 
fron the CEXFR versions because the invocation of any if-adced or 
if-renoved methods nust be CEVAL'ed. Since if-addeds and if- 

recoveds are probably not too closely linked with the process 
that trlfxers thee;, these are probably sale CEVALs. 

One worry the user doesn't have to have is whether his Lisp 
functions will clobber or rebind internal Lisp variables used by 
the Conniver interpreter. All Conniver atci^s Ccnniver doesn't 
UU ".: you to see have been "half-killed" in such a way that they 
will print out but cannot be recognized during user input. 
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ApE€nai>; 
Ihe Ccnniver Keference Source 
l.hereas tlie previous section of this man ual is a 
discursive overview of Ccnniver for the purpose of illustration 
of end introduction to the ideas embodied ijj Ccnniver f this 
section is an attempt to provide a reference source for the 
active user* Thus, it contains a detailed description of each 
primitive of the language, enumerating the possible error 
conditions that are associated with that primitive and its 
limitations which right not be immediately apparent* fesides 
primitive operators, every language has a set of reserved words 
(syntactic indicators and significant variables). These will be 
duly noted. A comprehensive index to the primitives, reserved 
words, and error comments is in the rear* Ihis reference 
material is divided into a section on the evaluator and a section 
on the data base functions. Ikch section is proceeded by a 
suonary of general information followed by a listing of 
primitives orfanized into categories* Lot surprisingly some 
; unctions appear more than once. The formal conventions of this 
section are: 

Actual code is in upper case 
Syntactic variables are lower case 
Optional arpunents are delimited by brackets ([.]) 
surrounding the syntactic variable and its default 
value. 
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Eejxejit syntactic variables are delitittc by stars (*). 

Every function defined \&s its type (or types) sijecified next to 

a sample call. Cli.ls and CLXPKs are ijivlsiLle iron Lisp and thus 

are only ceiinea in Coniiiver code, avoiding interference \.ith 
IIS1 fmcticns oi the sate r^ape. 
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T! e Evsluator 

The Conniver interpreter evaluates expressions in a 
canner similar to that of LISP. The basic syntax it* as follows: 

connlver expression = number | atoE f 

's-expression [| os-cxpression | (function 
*arruaents*) 

arguments = empty | connlver exrression i . . . 
rinniver expression K 

The evaluation rules are: 

1. As in LISP quoted expressions and numbers evaluate to 
tl emselves. 

2* The value of an aton is its value as a variable. If it is 
bound in Conniver that value is used; if not the LISP value is 
used* Thus, if a variable is unbound in both LISP and Conniver 
its evaluation results in the LISP unbound variable error. An 
error also results from the evaluation of a variable which is 
unaligned (though bound): 

UiJAESICJiED VARIAELE offendirc-variatle 

3» An expression following an <* is passed directly off to LISP 
for evaluation. We recommend that code be written so that as 
much as possible happens in LISP because of the considerable 
speedup attainable. 

<:. Junctional applications are processed as follows: 
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If the function is atomic, it is checker for Clii, CLXrh, 
CEHEBA2GB, IEXFL, PSUitf definitions. II an atot luis two cuUi 
definitions, the first on its property list is taker.; this Leans 
that if the user wants a function to be a HXEK in Lisp code ana 
a C XPR in Conniver code, the GEXEfi cust be defined last so as to 
be first on the property lict. If it is nohe oi the above, it is 
assioed to te a LIS1 EXPK, SULR, or LSULR, thus undefined 
fun* tion errors come frcm LISP. 

If the function is a ITiXPh or iSULK the form is passed to LISP 
for inmediate evaluation. 

If it is a CIHX (such as C01JD) the fore is evaluated fay the 
appropriate internal Conniver routine. 

If the function is a CLXPR or GEKEKATOE, the arguments are 
paired v;ith the foixal parameters of the function (and perhaps 

evaluated) as specified by the declaration in the function (see 

CDEUIJ, CDEFGEK for details) - After binding, the body of the 

* 

function is executed. 

If the function is an EXP£, SUIB, or I£U£R the arguments are 
evaluated by Conniver and then the LISP function is applied to 
tie resulting argument list with LISP APPLY. 

If the function is non-atonic then either it is an anonymous 
CLAKEDA expression (CEXER) or it is an anonyoous LAhEDA 
expression (EXPH) and treated accordingly . 

Mote that there are no other cases. The function position is 
never evaluated as in LISP* Functional arguments are handled 
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explicitly, preventing antiquity, usine the function CALL. 

Execution of the body of a CEXFh, Cli-ETvATOE, PROG or 
* ET OD proceeds as follows: 
If it ie£ins with the reserved wore u AbX u then the second 
elecent of the tody is taken as a declaration oi auxiliary 
variables (IROG variables in LIEF). Such a declaration i*> a 
mixed list cf atocs and initializations* lach atom is bound but 
left unassifiied. An initialization is a list of an atom and an 
expression. Ihe atom is bound and assigned to the value of the 
exp ession. 

The rest of the body is then executed sequentially (unless the 
sequence is changed by a GO). The value of the body (ana hence 
of the function) is the value of the last expression in the body, 
unless a return is forced by RETURN, EXIT* or DISMISS. 
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I. Cocr unicaticn with LISP 

A. (SOB [stuff KII]) IZUBx (but it evaluates its areuteut) 

B. (SlOP [stuff iHL]) LSWR 

There functions allow LISP and Conniver pro£rar*s to treat each 
^thcr as co-routines- Control is passed i*rcii Ccnniver to LISP 
vSa STOP and £ran LISP to Cormiver via LUiU Hie argument to STOP 
is returned as the LISP value of RUU and the argument of uUl. is 
returned as the Conniver value of STOP. STOP nay only te called 
if Conniver is running, otherwise: 

Conniver-KOI-flUWJIilO— STOP 
; UJ cay only be called if Ccnniver is not running, otherwise; 

Conniver ALREADY RUKEIHG. 
'XLjnple: To have Conniver evaluate expressions passed to it from 
LISP, we put Conniver into the loop: 

(PRCC "AUX" ((MESSAGE 'KI-LISP)) 
;LCOP (CSEIC I-XSSACE (CEVAL (STOP kLSSAGE))) 
(CO 'LOOP)) 

Conniver returns to LISP with the value HJ-LISP, Thereafter LISP 
cay pet an expression evaluated by Conniver by calling 

(EOS expression) 
Tl e value of RUK will be the Conniver value of the expression. 

ttithin a (Lisp) CEVAL, STOP causes its argument to be 
returned as the CEVAL 's value; this will be true even if Conniver 
control has left the structure that CEVAL set up, RUN will not 
£*et the program back to the execution point of that STOP, because 
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after leaving the CI VAL, Conniver is alieady running. So, if you 
want STOP to do the right tiling, don't use CLVAL. 

If, for some reason, the Conniver interpreter (not the 
data-base — see DATA-IEXS) needs to be re-initialized, at can be 
do: e so by executing (iron IJSP only): 

C. (KEAKE) SbxR 

START resets all of the Conniver internal variables (inclut-ing 
the earn) £n<2 £oes into the top-level listen loop. The data base 
is not disturbed, Ut all contexts previously bound only to 
Ci.nr.iver variables uill be lost to cartage collection. STAKT 
bines CCHTEW to a rloLel context containing CLCEAL as its enly 

c— frame. 

A Conniver program cay safely be stopped for examination by 
hitting "a (control-a). This causes a new car to be generated. 
The program can be resumed at the place it left off by exiting 

from the resulting listen loop via: 

D. (DISiass) CIMT 

AIsl see: EACKTRACE, LISTEN V/hen in Conniver IBASE=IASE=10. and 
all character macros are in effect; these return to their LISP 
defaults when returning via STOP. 
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II. Flow of control nodilicatiori 
A. (COICD clausel ... clauseH) CKiT 
Ci i.I in Conniver is almost identical to Cc;.X in LISr except for 
the fact that the CWi of a clause is a general lfiGG body. Thus 
it ray contain an "Mil" declaration (See Lelinition of 
procedures, PROG) and statement labels (tags). Thus enterir.£ a 
&..1 clause produces a cev; activation block so remecber this when 
usin^ EXIT etc. This is a legal use of COJ-E: 

(COKD ((= H 1) "AUX" l(K 2) (P (ACTLLGCK))) 
:LCOP (COI.I ({= (CSETQ K 7l- i-.)5 0) 

(GO 'LCCP)) 
(12)J 

i ext ve consider the unconditional transfer: 

E, (GO atoE or tag ) CIIiT 
GO elveys evaluates its argument, avoiding the anbi£uity of USF. 
If jts argument is an atorc, GO searches its environment for the 
nearest body containing (CTAG aton). This is abbreviated fcy the 
use of a LI£P character n^icro as tatom. 

Ccution : do not read Conniver code into LISP as the macros axe 
not in effect* 

Execution then proceeds from the statement label found- If its 
arcuoent is a tag (see TAG and ACTELOCK) control is transferred 
to the ta£, perhaps non-locally. If the ar£u&ent is of the wrong 
type or an atonic tsc cannot be found we get: 
LAD TAG 
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C. (HIT value [frace (AC..LLGCK)]) Clti'x 

D. (RtTURI. value) Cliil 

E. (DISIJSS [frame first non-C(Ji:D frace 1) Cli.i 

EXIT returns free the frame indicated with the value indicated. 
If no Irene is given it returns Iron the nearest activation 
block. Caution : CLKD causes an activation block, HETUhl*, 
returns fron the nearest non-COED activation blcck. DISiiISS is 
EXIT from the frace specified with the value i-.lL. If no frame is 
given it does a (KE'liRH KIL). If there is no activation blcck to 
KETURI1 fron or EXIT fron we get: 
KETUEK FROM feiKAI? 
or EXIT PROM UliAT? 

If DISMISS or EXIT is given a non-fraue they cocplain: 
LAD JRAJJE 

F- {ADIEU proposall ... prcposallO CIXPR 
G. (AU-REVCIfi proposall ... proposal^) CEXPK 

These functions return a possibilities list fron a generator, 

KO.Ling proposals 1 ... ii in that order. (Hone jiay be supplied.) 

(see NOTE). ADIEU leaves for good but AU-EEVOIIi finishes by 

noting a tag inside AU-REVOIB so that TfiY-KIXT can resute the 

generator where it left off. The value of AL-EEVOIR, on 

resumption, is the nessage passed in TR1-KEXT. (see Ifflf-JIEEL). 
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III. iTane i.anij.ulators: 
A. Constructor;:: 

1- (TAG atoiz) ZUIH 
2. (ACTELCCK) SULR 

-A* searches the environment for the first activation LiccL 
clii ainin£ a statement label :atoci. It returns a tag structure 
whuse frane is that activation tloch and whose tody-pointer is to 
that statement label* 

ACTELOCX searches for the first activation block (trace with a 
body] in its environment ana returns a tag to the beginning of 
the tody. If either a TAG or ACTLLOCX is unsuccessful in its 
search it returns iilL- 

2- (FRAME) SUER 

4. (ACCESS [frane (IRAKE)J) LSUIB 

5. (COmCL [frar.e (IRAKE)]} LSUUi 

HUME returns the trace with respect to which it was evaluated, 

AOESS returns the access frame of its argument. 
CONTROL returns the control trace of its argument. 
The argument to ACCESS or CCKIKGL must be a leriticate frene 

(*ta£ f *frare, ^closure). If it is not we get the error mesEage; 
SAD FRAME SUIPLIED 
6- (CLCSLTtE procedure) SUER 

CLOSURE produces the lambda- closure of the procedure (function, 
pener&tcr, cethod) indicated. Later invocation cf the closure 
(:ee CALL) causes the environment of the procedure (its access 
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>t,i ter, where it searches lor Mndin^a of iree variables, ia£S, 
etc. ) to be the environment in which the cltaurc was constrtctec. 
e-c- If X = 4 then: 

(CALL ((CLAliEXA (>.) (CLUSULE '(CLAliEDA (i) (+ X Y)))) >) t) 
has the value £ tut 

(CALL ((CLAfcaA (\) (+ X 1))) 3) 5) 
has the value S- 
This is the classical "rUiiAhG" device. 

£. Modifiers 

1. (smcCESS franel frare2) ' 'SUEK 

2. (SETCCK1RCL iraniel frame2) £ULR 

The; e very dangerous functions (for experts onl^) are used lor 
nodifing fraires. They set the access cr control pointer of iraoel 
to frace2. 

C* Interrogation 

(EXPRESSION frare) SUE& 
This function returns the expression whose evaluation created the 
frare supplied. It is useful for hunting arround in the frace 
structure. 
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JV- Relative Evaluation: 

A. (CEVAL expression [frame (ILAKY.}]) CIi»T f Ii.iiEfi 
This is the standard relative evaluation function. The expression 
is evaluated vith respect to the frame specified (default, the 
current environment ) as its acctss frame. 11 the fratie fupjlied 
is not legitiisate, we get: 
EAT IBAKE 

The LSUER definition of CEVAL can be used to do Conniver 
^valuations from Lisp. Unfortunately, if ycu use it to do 
something really clever, you probably are doing the wrong, thins- 
See "Lisp and Conniver" for an account of the dangers involved. 

E. (CALL functional argument argl ... argtJ) CI1.T 
tAL: applies the functional argument to the arguments supplied. 
It avoids the LISP ambiguity in the case that a functional 
argument is the value of a variable and we have no way of 
guaranteeing that it has no function property. The functional 
argument cay be a function, generator, or closure of a function 

or generator. 
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V. Variable manipulators: 
A. Interrogators: 

1. (VLOC atom [frame (IRAME)]) LSUER 

2. (RVALUE atom [frame (ERAME)]) LSUER 
% (CVALUE atom) PSUER 

4- (LVALUE atom) ESUER 

5- (ASSICKED atom) ESUER 

VLCC returns a locative to the value of the atom supplied if it 
is found in the frame specified, if not, it returns ULL. 

RVALUE returns the real value of the atom given in the frame 
specified (It does not check for *UI:ASSIGaEX). If the variable 
is unbound, in Conniver, the LISP value is taken. If it is unbound 
in LISP, the appropriate LLSF error occurs- If either VLOC or 
RVALUE are given an illegal frame, we get: 
BAD BRAKE SUPPLIED 

(CVALUL atom) (abbreviated ,atom via macro-characters) sets the 
current Conniver value of the atom. This is how LISP code called 
by Conniver code gets the value of Conniver variables. 

LV.LUE gets the LILP value of its argument- (LVALUE atom) is 
equivalent tc (tut not identical to) uaton. 

ASSICI.'IJj returns as its value, T if its argument has a value 
.other than -UI.'ASSICIIED) and WIL if it is unassignec. 

E. i.cdillerc: 

1. (CCLT ctom value [lramfc (rEAJJ.)]) LCULR 
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2. (C£EK! atct. valuej GfflL,SULH 

3- (Ui.A£SIGfi aton) EUih 

C T is the most powerful assifnjaeiit operator; it sets the atu& 
to the value relative to the fira&e cpecifiec. 
CS TQ is a cinGr convenience; it does not evaluate its i'lrct 
erfunent. 
UliASSIGH sets its argument to * UilA£SIGiiEb. 

C. there is one more function for working with variables: 

(L1KD atom value) SilER 

This is for experts only; it binds the atom to the value in the 
current frsre. 
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VI- Definition of Procedures: 

1. (CDEFUl atom declaration *fcody*) ILULU 

2. (CDEFGLK atom ceclaration *bocy*} iSUER 

These functions are used to define the atom to be £ functicn (or 
generator) v:ith the formal parameters specified by the 
declaration and with the body given, Functions are placed under 
the indicator CEXPfl and generators under the indicator CEfrE&AIGh* 
The body is sioply a sequence of statements to be evaluated 
sequentially. It may (or nay not) begin with a declaration cf 
auxiliary variables (described later J, The forcal parameter 
declaration syntax is as follows; 

declaration = ( obligatory variables options! variables 
exc ss ) 

obligatory variables = empty I pari ... EBSB 

garl = ator. | 'atom 

optional variables = empty f "OPTICKAL 11 o£[ ... oph 

opl = atom | "atom | (atom default) f ('atom default) 
excess = empty | "REST" atom f "REST 'atoc 

The semantics is as follows: 

1) Formal paramaters are matched against arguments froo left to 
right* 

2) There must be at least one argument for each obligatory 
variable. 

3) Unless there is an excess collector declared, there tay not 
be more arguments than declared variables. 
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<) Ar^ucents are evaluated unless the corre spending forsal 
parameter is quoted (*). 

5) If the arfiinents run out while bir.din£ optionals, they are 
filled with either *Uj:A£SIGKED, or if an expression for the 
default value is fiven* the value of the deiault expression (in 
the frame of the function with all previously processed variables 
bound) is used. 

6) An excess collector eels the list of arguments or values of 
i;r£im:ents (depending upon the existence of a *) left over. 

This elecant syntax is due to Chris Reeve of KUDDLL. Kote how 
beautifully this does away with TEXER's and LLXtfl's and how much 
wore flexible than LISP it is. 

IX the evaluator is not satisfied that the number of arguments 
is right for a function it complains: 

KROHG / Ox ARGUKEU3S 
If the syntax of a declaration is not as speciXied above the 
error Conner t: 

BAD DECLARATION 
vill be generated. 

To create a method we use the constructors: 

C. (IF-AEED atom pattern *body*) ISUEfi 

L. (IT-KEKGVED atoa pattern *bcdy*) fSUBR 

E. (IF-KEEEED atoia pattern *tody*) PSUEfi 
The given atom is defined to be a method of the type indicated, 
invoked by the given pattern, with the given body. The method 
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required is the value of the constructor. If the atoc i^ net 
specified, the rethod is not naced, but of course, it ney Le 
caved as the value of a variable, lo be accessible, a LCthcd 
nust be put into the data Lase via IKSHiX or AIIL, 

The body of a procedure is as follows: The value of a 
function is the value of the last expression in the body (or of a 
RETlRii, EXI1, or DlSHISS). The body is just a sequence of 
e:cpre£sions to te evaluated. If it begins with "AUX" (a reserved 
v/orc) then the next element of the tody is taken as a declaration 
of auxiliary variables (PKOC variables in LISP). Such a 
declaration is a list of atoms and initializations. Etch atom is 
bound but left unassiened. An initialization is a list cf ar< atoia 
and an expression- !ihe atoc is bound and assigned to the value of 
the expression. 
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VII Possibilities lists 

A possibilities list (created by XKLGn cr a ^eneratcr 

function) has tiie following forcat. 

possibilities = (*K2SIHLr±IE8 roel ... poeii) 
rosl *= (*I£2HQD pattern cethod)| 

(*GEKEEtA£OR foix)| 

(•AU-REVOIR body fr)| 

(•ITEii iten alist)| 

anytbinf. else 

Thus anything say 1* a possibility but the specifically sectioned 

tyres have special interpretation in: 
A, (Etf-fflEXT possibilities [nocore lOLJ [message EIL]) CSUItft 

TRY-NEXT is used to try the first possibility on the 
possibilities list. In doing so, it clobbers the list, relieving 

thf; first one. If there are none, it evaluates nocore end 
returns the value. The action taken by IRX-ftEXl on each type of 
possibility is as fellows: 

1. (*KEHiCD pattern if-needed Kethod ) 
The method is invoked. It generates and returns a possibilities 
list (protetly by either ADIEU or AU-REVOIR, though it cay COIJS 
one up). This new possibilities list is then spliced into the 
fiven one, replacing the method possibility which created it. 
TR3T-HEXT then loops back to try the first possibility in the 
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r.euy constructed possibilities list. The pattern is usee ty 
IM-AJiCL inside the method as the calling pattern. If an ii- 
needed or other kind of generator doesn't return a possibilities 
:ist to TRY-IJEXT, w).at it does return is ignored. 

2. (*GELERATOR form) 

Ex.- ctly the sair,e as a nethod except that the forn is evaluated 
rather than the petbod invoked. 

3. (*AL^REVOIK tody fr) 

This is the way AU-REVCIR can be resumed. The TRY-liEXT rocs off 
to the appropriate jlace in the AU-REVOIR which passed this back. 

The AU-REVOIR returns to its caller (the generator or method) 

with the optional TFJ-KEXI message ss its value. 

4. (*ITEH item alist) 

The alist is a list of variable- value pairs probably constructed 
by the catcher. The variables are set to the indicated values 
and the item is returned as the value of TRY-HDiT. 

5- Anything else is returned as the value of the TRI-«EXI. 

Thus we see that TJtl-KEXT does not terminate until either the 
possibilities list is ecpty i.e. (-POSSIBILITIES) or an item 
possibility or an "anything else" is first on the list. If TJtf- 

iE--. is given a bad possibility list we get. 
EAD POSSIBILITIES LIST 
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A method Dalies item possibilities as instances or its invocation 
pattern with: 

i - (IKSTAJXt) xSuLK 

which returns the current instance. It will £et upset if there 
are unassicr^ d variables in the pattern and will cry: 
II-HiRE IHSXAHCE 

A generator or i^ethod aay note a new possibility via 

C. (i;OTE [possibility (IL£TAHC£)j) LSUEfi 

The list of possibilities that have been noted since the 
generator was started (or last resumed at an AU-REVOIR) is stored 
in a variable, PKOICSALS, in the reverse order of notation 
(chronologically)* This is the list which is reversed and 
returned (with *PCS£IEIUTIES COUSed on) by AU-I.EVOIR and ALIEU. 

If a generator (or a method) wants to get (to see or clobber) the 
possibilities list of the IRY-liDCT it feeds, it can: 

D. (GLT-F0SSIEILI1TES) ISUER 

It can replace the possibilities list of that U.X-KEXI by: 

E. (SET-PCSSIXILIIIES possibilities list ) EXFh 
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\III* Detugfin^; Aids 

A. (EACmACF [number 6S6S6SJ) LLXI-h 

BACKTRACE, types out, in a very reacable Tern, the expressions 
corresponding to each trace of the current process, starting with 
the current fraire, and proceeding t*j control linlfs to the tcp 

level. The optional numerical arcutent cay be supplied to limit 
the typecut to that i&any fraiaes* 

B. (EXPI1E££I0JJ frsce object ) ZXIH 

Has as its value the expression of the frate, tag, or closure 
passed to it. This is useful to find out what in the hell is 
iCEing off when you are playing with control structures* 

C. (CTAG ctoe) FEXPR 

Ti" s is the internal representation of :atcni, a statement label. 
Please note that the LISP trace pacLage can be used to trace 
CuJt 9 thus showing your flow of control. 
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Tl e Data tc^e 






The Coimiver oata base is a hierarchical structure of 
contexts , or a "tree," of con tex t- frames , contaii«in£ four types of 
t:t : oijects , items , me tl iocs , arid Lethod closm-es . 
Objects are of the iorm: 

(*OUECU arbitrary-structure *c-mari;ers*0. 
I tecs are of the fore: 
(name *c-markers*) 
where name is any non-circular list structure. 
Methods loot like 

(type name pattern body *c-markers*), 

whe. e type is XF-UEEDED, IT-ADDED, or IF-EE-.OVH; name is ar. atoia 
which is the method's name unless it is NIL; jattern is a non- 
circular list structure with all variables (if any) marked cs 
tOIVEH var) ("?var") or (ASSIGN var) ( u !var"}; and body is a 
; enera tor- function tody if type is IF-i*EEDEb, and a CEXFR body 

otherwise. Any atoE with such a structure on its property list 
und*r the indicator tiETKGD is equivalent to that method in every 

situation as far as the system is concerned, but the atom must be 
the name of the method. 

Method closures look like 
(•CLOSURE method fr), 
where method is a method (possibly specif iec by name), and ir is 

an internal frame pointer. 
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All suck data have {j»OGsibly i.IL) lists of i- markers 
associated with thet. A oirarker is of the fort 

(cnum status *property-pairs # ) 
wi ere cnun is a c-frame nutter; status is +, -, or i.IL, 
indicating realization , unrcaliEation , or imsi ceil"! cation in that 
c^fVane, respectively; end property-pairs arc norr-atotic s- 
exprecsions- The c-carkers on each datut are in orCer of 
decreasing en urns. 

A c-narlter indicates a rent ion of its da tut by its context- 
fru^e* A ccntext-frate (c-fraiae) is of the fort 

(*CTRAME cnut *cata*) 
where cnuc i£ its unique context— frame number, and data are the 
data it mentions. If cnum = 0, this is the f^olal con text-i rase 
CLOEAL, for which data always = KIL. 

A context is a list like 
(*C0KTEXT *c-frejnes*) f 
ul ere o-frares nust be in order of decreasing cniass, with c-frate 
CLOLAL = (*CTRAK£ C) as the last one* It is worth tentioning 
here that none of the functions that defend on an explicit or 
im; licit context arruaent check for the presence of the *C0i.TEXT 
fla/~ at the beginning of the context. Hence, any list with a 
list of c-frates as its car is a le^al context; in particular, 
(CL- context) = (super— context context) for all practical 
purposes, 

Each context rigorously defines the status of every catuo as 

- * 
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present or absent , as follows: if the first st^tus-de finite 
mention of the catur by a o-frace in the context specifies 
realization (status = +), it is present, else absent; in 
particular, if it is unspecified by all c-lranes in the context, 
it is absent. 

Every o-i^arker rust specify either non-KIL status, cr ncn-UL 
property-pairs, cr both, and cannot be (0 -), or it does not 
constitute a mention. System functions delete ell c-carbers of 

the form (n UXh) or (0 -). 

When a o-fTame is net pointed to by any thine, it is subject 
to faxtage collection. All c^markers embodying a tentictt by it 
till be deleted iron their data. 

Items, irethods, and method closures axe indexable data; they 
can be referred to by pattern in IEl'GH and ether functions* This 

inu f xinp is done autonatically by the system vjhenever an 
unmentioned datur becomes mentioned (by ADD, REMOVE, LPUX, and 
other functions); urindexinr occurs when its last mention is 
removed (by DRH:, the carba^e collector, etc). Unindexed itecs 
and anonymous methods are subject to garbage collection if 

unp, ctected. 
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IjiU— Base xiTiCticns 

These functions are tightly interwoven. Ihcy all call a 

common tody of invisible functions which analyze their argents; 

it is these that print cost error cessans* ' way lunctiuns 

generate the following two lesse^es: 

TCO JEW AKGUtiEUlfi 
TCO HANI AKGUI1EK1S. 

These viU te acconjenied by a print— out of the fore that caused 

the trouble. 

liany functions use system routines to break a datum into 

usatle chimin. They can £enerate the messafe 

IIEAiaKGLESS DATUK — function, 
where function is one of ANALYZE, CHARXiES, or IATTIRK, 

Functions tl^at t ake skeletons instead of patterns as 
argunents resent finding "?" or "!" in then. They generate the 
message 

VAKJAELES Ih A SKELETON — INSTANTIATE 
(IICTAi.TIATE being the routine that generates an itec iVon a 
s 1 e eton). 
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(IAIA-IKII n n) sui* 

This function wipes out hT currently existing contexts, ana 
unindexes all indexable tiata. It creates a brar.d—new data i^se 
governed fey the paranters n and c n is the total nuc.ber or o* 
franes allowed; if the data-base functions ever attempt to 
maintain aore than this number at once, the nessa^e 

TOO KAIIY COKTEXT-FRAiiES — CHUTE 
will occur. (See CJKAHE for a core cojsi]:lete account.) 

The second parameter, m 9 is the increment between the nuobers 
of context-frames consecutively generated by CIKAiX* Given the 

ordering constraint on c-frajnes, find the fact that SHJCE (cv.) 
cust be able to generate c-frames with cnuns between these cf any 

two c— frames, even if they were generated censecutively, they 
c&tj ot be numbered C, 1, 2,,,*, but 0, &, 2l, ^h,**,. 

Conr,iver does a (DATA-IKIT 100. 10.) when it is loaded, 
creating a data base with at most ICO enframes at a tiice, 
juntereo (GLOBAL), 10-, 20., 30...... 
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II. E atur Creation 

A. (CUICT [stricture lilt}) LSUlii 

creates a brand-new object of the form (*OLJECT structure), where 
structure is artitrE-ry. This object is initially absent in all 
contexts, and, cf course, not EC to any other. 

If GEJECT has too cany ercuaentt., it errs with the tesse^e 
TCO liAtfl AfiCUMEJ.TS 



b. (DATUM skeleton) SU£fi 

Item data are ncnaally created implicitly whenever the user 
nan-, s ore with a skeleton that does not refer to any currently 
indexed itec datum. If, hoi/ever, the user creates an item catux 
hicself, by using LIST on a name, or using the "simulateu itec" 
of an instance proposal, etc., it is obviously ^uarenteea net to 
be EQ to an indexed iten datun with the saae naae (if any). 
Thu , if he executes (KEALIZE (LIST '(LliiE GC01))) and ((LIkE 
GCO ) (£ -)) is already indexed, the new one will be indexed as 
well. (The indexer could check for this, but it would slow 
thiif-s down.) Then IETCK will find both, and EKESEJT will find an 
unpredictable one of theo. To r_et around this problem, use DATUM 
instead of LIST. After instantiating skeleton (like ATE), lATUr; 
returns LIST of the result only if it can't find it in the index; 
if it can, it returns the unique iten datuc with that 



instantiated skeleton as its nace. 
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JII. Enlarrju^ , LejOetij^, tj\& Search in/ the lata Laun 

A. REALIZE datuc [context C01JT££i 1) Ci#lR t l£UU< 

UISIALIZE datum [context COl.TLXl]) CEXIft,LSliLR 

ADD skeleton [context CUJTEXI1) CEXlR.LSUln 

liBLVE skeleton [context COi/iLXSll CiiX11;,LSijLK 

IKSLRT skeleton [context C0i;TEX r i1) LSU1R 

KILL skeleton [context COKTOTJ) LSULR 

These functions italic datum present (REALIZE, AED, USHCi) or 

absent (UHREALIZE, REMOVE, KILL), by virtue of realization c-r 
unreal! zat ion in context's first contexk-frai;e. Here, "datum" 
r.uar." datun (REALIZE, UliREALIZE) or "item datuc referred to by 
ske eton" (ADD, RBiCVE, IkSIRT, KILL), /JO and REICVE can be 
used to alter the status of date not referred to by skeleton; see 
lll.B* 

The effects cf these functions are invisible in all super- 
contexts of context; these effects will be collected as cartage 
if the top c-frace is ever caught unprotected by the garbage 
collector* 

If AED or REALIZE is given a skeleton or indexable datun 
argument, respectively, all if-added methods catching datum's 
namr that are present in context will be invoked. Similarly, 
ilfiEALIZE and REKOVE invoke if-recoved methods catching datum's 
rati * 

Warning! The LSUER versions of these four functions execute 
hidden CEVALs to accomplish the method invocations. If the 
methods do anything really clever and subtle, invoking then will 



eAQL IA 



protahly screw your pro^xsc. 



B. (ADD nethod r context CCK*fcXTl) CEXTR t T. c . 



ADD retl.od f context COl&fcXT]) 

RHSGVE i-ethoa [context CXJilTKl - !) CLXH: 1 L£o"I-s 

II.'SLRT nethod [context CGiJTEXl]} LSULft 

KILL nethod [context CUi/LtXlJ) LSULR 

If ADD and f-JHiOVL are £.iven cetLoci, itethod nane, or i^etl od 
closure arrucents, they are synonymous with JiLALIZE and 
IK'XALIZEj the cane is true of ZfiSBiX and KILL. These functions 
can not he fiven any other catuE types as arguments, (Since 
the:e is no \/ay to tell whether ({.FOQ LAfi)), for exacple, is 
peart to be an item or the name of one. ) 

C. (FETCH pattern [context COliTEXIj) LSUEfi 

(FETCHI pattern [context CGWTEXXj) LSUth 

(FETCHK pattern [type IF-KEEGEDj [context COKTBCTJ) 

FETCH returns a possibilities list consisting of item 
possibilities for all itecs present in context that catch 
pattern; followed by nethod possibilities for all if-needed 
methods in context whose patterns match pattern* For the fcraat 
of these lists, see "Hairy Control Structure," 

FETCHI returns a possibilities list containing enly the item 
possibilities* FETCHH returns a list of only the method 
possibilities of type type that are present in context and fratch 
pattern. 

FETCHK cay spavn the error cessage 



TOO KAiJX AMUI-TOS. 
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IV. Pr over ties cf Leta 



A. 



REAL datun [context CCiiTL£n) LSULR 

.Ui.'RLAL catuc [context CUTXXil) LSULR 

PRESENT pattern f context CGLTEX'il) LSULK 
AESLLT skeleton [context CGl.TLXi 



LEULH 
LSULR 

These functions return catue if and only if it is present 
(REAL, EHESEKT) or absent (UiREAL, ALSEI.X} in context, and i.IL 
otherwise- REAL end ULRLAL axe lianded their data argucc-nts 
directly; PRESEKT tries to return a randouJy chosen present 
itec that catches pattern; AEBEHT takes DAiUM (qv.) of its 
ske eton and then calls UiiRLAL. 

PRESEiil behaves a lot lite (THY-iJEXJ (IHCB pattern)); in 
particular, it assigns any "?"- or "! "-narked variables in 
pattern to the pieces of the itec tfcat they Ciatched. 



] . (DPUT datum property indicator [context CCIiTXXTl) 

(DGET datum indicator [context CGl.'TEXT]) LSULR 

(DRJ3-. datun indicator [context CONTEXT j) LSULR 

(DPUT+ datun property indicator [context CGMEXtj) 

(DGET+ datuo indicator [context CQKTEXT1) LSUIR 

(DREM- datum indicator [context CONTEXT]) LSULR 

(DPUT- datum property indicator [context COJilEXtj) 

LSULR 
(DGET- datum indicator [context CORTEX!!) LSULR 
(DnlJi- datum indicator [context COiJTEXTj) LSULR 

DPUT associates the pair (indicator property) with datuc in 
the first ("cost local") c-irane of context; like REALIZE, 
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iJIiZALIZE, slid their ill:, these effects are invisible above 
context aic carfc£££-collecU-ble ^* i** s l^P G-iruae is reclaimed. 
B;.'E finds the first pair associated with Indicator in any c- 
XraciiO of context, startii.£ vith its first c— i'raie; if there is no 
such pair, its value is i^IL. LfJJi lias the sane value, but 
re&.ves the pair as a side effect. 

DPLTT+, LGET+, and QREBt are exactly the sane, but they t-ttend 
only to the c-frames in which datum h&& realizec ("+") status, ug 
to the first c -frace in which datup is unrealized. If EPU2+ is 
given a datum which is absent in context, the error message 

AESEKT LATUIi — UPU1+ 
occurs. 

DPUT-, LGET-* and LKEIr- are exactly analogous, but they 
ignore a! 3 ii*aces with status 5* "- 11 , and all franes after the 
first in winch catut is realized (marked with "+")* In addition, 
if the catuc is absent by virtue of unspecified status in all c- 
frares of context, EPUI- uses CIAIAL as the rejxsitory of its 
properties; DGI2- and DREIt- treat CLO£AL as specifying 
Lineal izati on if its c~carker on datum is carkec UIL as well as 

if it is narked — - 

If E'HJT-'s argument is in fact present, the error r.essa£.e 

PRESENT DA1UK — DFUT- 
is generated • 
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C. (I)FinCf' cctun property iriGicatcr o-i'rajiie) .SJfch 
IDGrsCf catuci Incicator c-1'rai.e) £>UJJi 

(DrerCi catuir, indicator c-fracio) 5U£J-, 

These functions nanipulete properties in tin explicitly fiver. 
context- frare. DPUICi associates property with indicator in the 
c-marker for c-frarc on oatur.; if there is no cuch c-carlxr on 
i atuo, tPUICF puts it there, without changing its status. As 
usual, these effects are invisitle in super-contexts not 
containing o-frare, and fill be cartace-collect&d if o-frecc is. 
CCETCF and DKEKCF search that c-carJter for a pair with first 
eleirent s indicator, and return it, or EH if there isn't one; 
DRH;CF removes what it finds. 



riO£ tS 



V* rxmiTUlatinr Contexts 

A* (CJRAI1E) LSULR 

CFRA1-1L returns a new c-ireue with a number higher than that 
of any other* (It uses the second arctuaent to lATA-Iiill lqv,) t 
adding it to the previous one it generated.) II there are cs 
many contexts already as provided for by liAlA-IMT, CfEAuE calls 
the c-fr2iie £arta£e collector to free space for nore. If all th< 
pla< es are taften, the message 

TOO KAS.T COliTEffl-IRAI-IES — CSKMX 
is generated. 



E. (PUSH-COliTEXT [context CONTEXT]) LSUIR 

(FOF-COiiTEXI [context COi.TEXIj; LSUER 

JIIE^COI^EXT c-fraae-list) SUER 

(SPLICE context J SULJt 



These functions create new contexts, and return thee. j-USjj- 
ar.d pOP-COiJTZXT return contexts with one new c-irane added to, or 
the front o-fratte removed from, context, respectively- If JOP- 
CUiTEXT tries to pop the last o-frajne (i*e., GLOBAL) off, it errs 

with cess&ge 

EKPTY CONTEXT — POt-COliTEXT- 
NEW-C0J.1EXI creates a context by COKSing the flag *CC1.TEXT 
onto c-frace-list. The c-frames in the list cust be in order of 
decreasinc cruras, or the message 

imiDERED CONTEXT — NEW-CONTEXT 
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appears, Iti addition, the systtc refuses tc create a new ccntcxt 

without GLOiAL as its la^t lrace, and will hPLAlU GLLIAL i- if .it 

isn't there, 

SPLICL adds a brand-new c-frace to context, just after its 

first frane, Ihis c^frace will have a currently unused nunier 

between those of its successor end predecessor. If all such 

numbers are in u^e, the error cessa£e is 

TO EEB Ci;UH EETVJEEN low MO) high — HEWC3UM 
:PLICE is called for its side effect. Its value is EQ to iis 
argunent, but changed, of course. 

Since SPLICE and PUSK-CUJTEXT call CHiAhE, they can cau^e its 
error, 

C- (IB-COflIEXT context forn) CEXffi 

CEV/iuates form with CONTEXT rebound to context, liius, for 

exacple, 

(Ut-COUTEXT C1 '(ADD '(IALL SKY))) 
is equivalent to 

(ADD '(FALL SKI) C1). 
In general, Ilt-COKTEXT allows you to pretend any function t&ies 
an cptional context argument, (There is no SU£fi version of this 
profraia because it must rebind a Conniver variaLle,) 

C. (KEKTIOKHRS datum [si£*i IJIL] [context COMBES ]) . 

LSUER 
(C-HABKEfi datum c-frace) SUEK 

KEL'TIOIEKS returns a list, in decreasing c-frane-numcei 
order, of all the o-frares in context that mention datuc. If 
sijx is non-KIL (i.e., + or -) f it ignores all Lentions with 
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s atus f Bioi, except that ii" si^n = -, a oenticn by GLGLAL 
specifying no status is cow. ted as unrealizatioL in GLOiAL. If 
sifji does = i.IL, 1'XJ.TIUijJcS returns all aentior.ine c-fraaes. 

C-KARKEf. returns the c-Larkcr oi" datun with ciuaa «= i-uuhtr of 
c-frane, or LIL if ©-frame doesn't mention uatut. ir c-fraie is 
subsequently £arba<e-collected, or the c-narker ceases tcinr a 
mention, the c-tariicr will r.o longer be attached to datuiu. Jiever 
say Conniver didn't £ive you enough rope. 

E. (PATH context) SUIR 

is a debufc*n£ convenience. Its value is a list whose first 
element is *C0KQHS, followed by the cnuos of context's o-tframes* 
Such an object serves no useful purpose, but it is nuch acre ©ore 
lucidly printable than context itself, in general* 
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